Many companies struggle with the challenges of reconciling the need for strategic planning and the desire to execute in an “agile” or Agile fashion. Generally speaking, this is because they’re stuck with the perspective that a “roadmap” must be a set of promises regarding what’s to be delivered, and not merely a strategy that will and must change over time. Being “agile” requires that we accept the unknowns in the world — and what’s more unknown than what the market is going to look like in 2 years? Therein lies the folly in trying to perform traditional roadmap planning and expecting to be able to be “agile” in your execution. But, there are some easy ways to change your perspective on roadmaps and maintain the balance between strategy and execution.
The Tension Between Strategy and Agility
To understand why and how we need to balance the two, we first need to explore the tension that exists, and how this has traditionally played out in organizations who struggle with Agile planning. In the “old world” of Product Management, we were usually expected to have a 12-24 month plan that specified exactly which features were going to be delivered across all of our teams, and when they would be delivered. At best, this was right about 25% of the time — doing a quick review of any company’s prior roadmap plans should provide you with ample evidence of this. Why was this — simple, the roadmaps were always based on commitments and “contracts” made based on what was perceived as a complete set of requirements, but which were in fact an ever-changing checklist of deliverables. I can’t recall any time in my career when a waterfall-planned project was actually delivered on-time, within-scope, and within-budget (either money or resources) exactly as it was defined at the beginning of that project. These kinds of roadmaps were nothing more than a crutch for senior management, who wanted to be reassured that there was a plan, and that people were doing what they were expected, as well as a tool for sales to reassure the customer that the one feature they wanted was coming in Q2 of next year…even though it wouldn’t actually ship until Q3 or Q4, if at all.
Agility, on the other hand, lies on the opposite spectrum from this perception of certainty — at least when taken to its extreme. We know what we need to do right now and we work on it until it’s done. Then, we take the next thing that needs to be done at the time we’re ready to start it. And we repeat the process, always focused on the one thing that’s most important at the time we start it. It’s got a great counter-culture feel to it, and there are many developers who love it because there’s no bullshit involved. If it’s important, you do it — and you take the time that’s needed to do it right. After all, if you’re being properly user-centered in your prioritization, whatever it is that you’re working on must be the best thing to work on, right?
But therein lies part of the problem — taking agility to the extreme results in simply a series of projects that are disconnected from one another. Just because it’s important doesn’t mean that it can be easily packaged, marketed, and sold to customers. Agility taken to this extreme isolates the product from all the other functions of the business, and while it sounds attractive at first, it has some massive effects further downstream. It’s an unfortunate fact of life that just because you’re solving the “most important” problem that your customers are facing, if you can’t market and sell those solutions, your business won’t succeed. A business is more than just a product — and all that “bullshit” that many developers dislike so much is what actually keeps them employed in many markets.
So, on one hand we have the traditional expectations of the business side of the house, looking for a perceived certainty and a security blanket provided by a feature-specific roadmap with tight dates and clear deliverables. And on the other hand, we have the desire to work on the things that are most important only when they’re the most important, taking each thing on in a “just-in-time” planning process that focuses on delivery of quality solutions over the business “bullshit” that clouds our judgment.
Reconciling Strategy and Agility
But this doesn’t have to be a dichotomy! In fact, most organizations are far more “agile” than they actually realize, and with a proper level of involvement and understanding of the reasons and goals that company strategy brings to the table, developers “get” why they might work on something that’s “less important” but that actually feeds the revenue pipeline.
Transparency First
The first thing that any company should do is to ensure that there’s transparency into the strategic and tactical planning process, throughout the organization. Strategy isn’t something that should happen in a backroom meeting amongst the C-suite or Exec Team; it should be an open and honest discussion about what’s important to the company and where they view the market, the customers, and the company as a whole going in the future. Feedback should be solicited from all teams, as everyone has some level of experience and interest in ensuring that their voices and the voices of the customers they serve is heard — and this includes Development and other technical teams as well. When everyone understands why and how a strategic plan was achieved, there’s a lot more buy-in on the day-to-day level than if it’s seen as a proclamation from on high handed down from the C-suite on etched stone tablets.
Thematic Roadmaps Only
The next thing that a company should do is rethink how their roadmaps are structured and what the purpose of them actually is. Get rid of the “security blanket” of false certainty on the roadmap — accept that things outside a 3-6 month window are increasingly uncertain as that time horizon expands, and create a roadmap that reflects this. While you should probably be rather certain about the things you’re delivering in the next 1-3 months, and you likely have a good idea of the things you’re delivering in 3-6 months, beyond that you’re just throwing darts while blindfolded if you attempt to get to a feature-specific level. Rather, on that 6-12 month roadmap, you should target “themes” or general areas that you plan to focus on, and fill in the details as you get closer to that date. “User Experience Improvements” is better than “Create new sign-up process for new users,” because by the time you reach that 6-month mark, it might be that customer acquisition isn’t your biggest UX problem! Thematic planning allows you to provide a guideline for what you’re likely to do, but doesn’t lock you into specific deliverables that might not actually make sense by the time you start them. It also allows your Product Managers to give good prioritized backlogs to the teams, as the thematic goal of the quarter can be used as one of the primary prioritization tools — if there’s a feeling that one thing is more important than another, you can always ask “How does this contribute to our Theme for the quarter?” and use that answer as a touchstone for determining priority.
Planning Needs to Be As Iterative as Execution
Once we accept that our roadmap isn’t as certain as we used to pretend that it was (really, think about it — were you ever really convinced you’d deliver Feature X in Q3 of next year?), then we can start to incorporate many of the same agile practices in our planning process that we do in our execution process. We can revisit the roadmap on a regular basis, we can adjust it for current conditions and new predictions, and we can reconcile what we thought we could do with what we actually achieved. The roadmap, then, becomes a tool for constant organizational improvement and alignment and not some mythical Oracle that tells the future without regard for reality. Further, when the technical teams that have adopted their own Agile methodologies see that the business side of the house shares some of their values — such as responding to change over following a plan — then there’s a stronger bond formed between those teams, and a greater level of trust, respect, and cameraderie develops naturally, which makes everyone’s job easier and more satisfying!!
