Probably the single most common question that I run into nowadays is which process is the “best” one to be Agile, with a capital “A”. And people are often surprised when I tell them there’s no right or wrong answer here, but that they’re focusing on the wrong thing if they’re trying to be Agile before they’re agile.

I know, that sounds confusing, but the world of Agile often is confusing to people who are new to it. There are any number of up-and-coming development practices and project management practices that one can use to achieve the goal of being Agile, with a capital “A”. But, the simple fact is that none of these matter unless you’ve fully embraced being agile with a lower-case “a”.

I firmly believe that agility is not just something you practice, or some tool that you adopt and adapt — it’s a quality that you have, or that you don’t. Don’t get me wrong, all of the well-known frameworks – Scrum, Kanban, Scrumban, XP, etc – will help you to be more agile, but none of them will make you agile if you’re not already thinking that way.

Agility is not just something you practice, or some tool that you adopt and adapt — it’s a quality that you have, or that you don’t.

I’ve seen too many teams put the cart before the horse, and start trying to wedge these processes and their supporting tools into their world before they’ve actually figured out the importance of agility over Agile. I’ve also seen situations where some dictate comes down from on high that “the business” want their teams to be Agile, but without understanding the implications of agility on the company as a whole. Both of these situations are doomed from the beginning, because they’re putting Agile practices over practical agility.

Being agile (lower-case “a”) requires that a business realize and internalize the fact that a 2-year roadmap of specific deliverables, all tracked down to the Gantt chart level, is ridiculous in this day and age. It requires that Product Managers give up on elaborating and defining every single use case that could possibly be covered by the product they’re working on. It requires Sales to stop relying on feature delivery and focus on value selling. It requires Marketing to change their approach from release-milestone marketing to opportunistic and message-driven marketing. And it requires Developers to become true problem-solvers, not just order-taking custom coders.

All of these changes are very real, and necessary for the true success of any Agile process. You won’t be able to effectively run Scrum if Sales wants a 2-year roadmap to make promises to your clients. You won’t effectively run a Kanban process if the CEO wants to know what’s going to ship in 6 months. You won’t effectively implement Extreme Programming practices if Marketing is planning their messaging framework 9 months in advance.

So, who’s job is this? It’s yours – the Product Manager. You are the agent of change in your organization, leading through influence and social capital. You are the one who needs to manage the backlog, prioritize with stakeholders, massage the other groups in the organization so that they fully grasp not only the what but also the why of being agile and using Agile processes. You are the bannerman, and you need to motivate people throughout the team to be more agile, from beginning to end. It’s not a hard sell, so long as everyone knows what’s in it for them, and most importantly, for the customer. Being “agile” lets us focus on what’s needed now and in the short term, ensuring that we’re delivering what’s actually valuable to our clients and customers, not just prognosticating what they may need in the far future. And being Agile means that we’re using proven processes that can be adapted to implement, track, and report on these goals. Agile without agile is like a car without a steering wheel – sure, you can go somewhere, but it’s not where you want to wind up.

You are the agent of change in your organization, leading through influence and social capital.

Simply put, being “agile” is about embracing change as a culture – it’s something that you are as a person, a department, and a company. It’s not just some new and fancy process that you read about online, it’s something that should be reflected in every thing that you do.

Here are a few tips on how to become more “agile”:

1. Start with the customer first – talk with them, embrace their problems, dig deeper on what’s really troubling them, not just what they say they want.
2. Create a prioritized list of actionable work – this is not a “roadmap”, it’s a clear and understandable list of the top 10 / 15 / 20 things that your customers need now.
3. Accept the “unknown unknowns” – you don’t know what you don’t know, so stop pretending that you do.
4. Embrace uncertainty and drive it out – If something’s unclear, test for it and accept the results, whatever they may be.
5. Fail fast, fail early, fail often – The faster you can rule out an idea, concept, or project, the faster you can move on to something more valuable; prototype, paper test, A/B test all of your new ideas before any developer sees them.

As the aphorism says – “Be the change you want to see in the world.”  If you become agile, and can demonstrate the value of being so, others will follow.