Most roadmaps are an orchestrated delusion meant to preserve the illusion of control
An elaborate roadmapping circus prevents companies from having to face the uncomfortable truth that we can’t have total control
I had trouble sleeping during the weekend because I was anxious to experience that most terrible day of the quarter again — the roadmap show and tell.
On that glorious date, all Product Owners are summoned and condemned to sit in a meeting room a whole day to discuss the roadmaps of all teams with a time horizon of nine months — including precise dates for every high-level feature and mapping all dependencies with other teams.
That’s one long sentence, but trust me, by experiencing the length of that sentence, you now have a better understanding of how I felt at the time.
I’d also have a separate meeting with only the domain owner and the CEO present. Please don’t ask me why we had a domain owner on top of a Product Owner.
During that meeting, they would grill me on every detail present on the roadmap to ensure we were on top of things. Hesitation to answer any question was a red flag. Total confidence was expected.
After that, we were all left to our own devices and free to do our own thing. The roadmaps were stashed away until someone acted like they were important again.
The roadmapping circus brings management joy
The whole roadmapping process was a carefully orchestrated circus down to the most minute detail. There were rules that specified how big something on your roadmap was allowed to be. How dependencies should be indicated and the exact business case format you needed to follow. We even used a whole spectrum of colors to mark specific scenarios.
If more elaborate rules would produce better roadmaps, then we totally nailed it.
Our roadmapping approach was all about features and their timelines. Deliver X by Y. We rarely talked about the customer. The business cases firmly rooted in our imagination were there to prioritize the different features and resolve scheduling conflicts.
In other words, there was a clear incentive to tweak the numbers, and this was precisely what happened. Every domain had its interests at heart, and the numbers were a powerful vehicle to protect the value of your precious little kingdom in the eyes of management.
You might be thinking, with such a carefully crafted and meticulous process, “Surely we’d be delivering results and collaborating effectively”. The fact of the matter is we weren’t delivering. Most roadmap items were never completed.
When we unexpectedly needed help from another team, the first instinct was to ask the following question: ”How can we solve this problem without asking another team for help?”. If it was on the roadmap, we got help. If it wasn’t on the roadmap, well, good luck there! You’re in no man’s land.
The whole process prevented the delivery of value and felt like a game. Respecting the roadmap was more important than doing what’s right. Our roadmaps were delusional and not firmly rooted in the reality of complex work. But every quarter, we had to pretend like those roadmaps were vital to our success.
The purpose of the roadmapping process was to give off the impression of control — we put a lot of thought into it and pretended to know everything. Our managers could wave the roadmap in front of their manager, and *poof* all difficult questions would disappear.
Preserving the illusion of control was more important than doing what was actually most valuable. In a single word, I would describe the roadmapping process as insanity.
I never bought into this form of collective madness, but I had to participate in it due to pressure from management. Management celebrated the roadmapping circus as the best thing ever. If anything, it only destroyed any chance we had at delivering a valuable outcome.
Why are feature and timeline roadmaps appealing to management? Why don’t they work? And what should we be doing instead?
The appeal of roadmaps with features and timelines
Roadmaps with features and timelines are appealing because of three beliefs many managers hold that I see as wrong:
- Business cases only rooted in our imagination are reliable.
- Delivering features is equal to delivering value.
- Improving coordination between different departments is best done with roadmaps.
I’ll now explain why all of these three beliefs are wrong when you do complex work.
Incorrect Belief #1: Business cases only rooted in our imagination are reliable
Business cases often are based on a significant amount of assumptions with a ton of variance. When you prioritize based on this noise, you’re not prioritizing based on value. You’re prioritizing based on rubbish. But we like our thoughts and want them to be right as much as possible.
It would be much better to do small experiments to reduce the variance and challenge your assumptions. And then use this information to generate sound business cases that are rooted in reality. Except, working this way will make predicting timelines and what features we will deliver even more difficult. Management no likey, and therefore abandoning command and control rarely happens.
The comfort of knowing what features we will deliver by when is often considered more important than doing what is most valuable. Just because features and timelines are easy to measure doesn’t mean they are important.
Incorrect Belief #2: Delivering features is equal to delivering value
This is the most pervasive misconception. Just like telling a joke doesn’t mean people will laugh, delivering a feature doesn’t mean it will make customers’ lives better.
Imagine you’re a comedian, and you know you need to hold a new show in Las Vegas nine months from now. Would you spend those nine months contemplating about what jokes you’re going to make and then do the show? Of course not!
Comedians do dry-runs and tryouts to check how their jokes land. When the audience doesn’t laugh, the joke needs work, or they need to leave it out. When the audience does laugh, that means there is something there. By playing around with the narrative structure and delivery, they can generate even bigger laughs from the audience.
It’s not about what you build but how it is received. That requires listening to your customer and adapting it based on the feedback you receive. Build and forget doesn’t enter the equation, which is what feature-based timeline roadmaps often lead to.
Incorrect Belief #3: Improving coordination between different departments is best done with roadmaps
Many roadmapping processes are a response to scaling problems. Our teams have trouble coordinating and the roadmapping process is there to force collaboration. Our roadmap is an artifact we produce to help us work better together.
The optimal way of dealing with complex work means to strike the right balance between foresight and afterthought. Acting based on what we know beforehand through planning, analysis, and design, and responding to what you discover by being flexible and acting at the moment.
Most coordination and communication problems are not solved by roadmaps. When you discover what you can’t and don’t know yet, feature-based roadmaps with timelines can offer no source of relief apart from sticking to the plan.
You can’t coordinate and communicate based on aspects you don’t know yet. The only solution is being able to swiftly react when you discover new problems or information. Many Scrum Teams are not that flexible during the Sprint, let alone when other teams need their help.
When every team has its own roadmap with accountability, matters become even worse. There is a clear incentive to ignore other teams to ensure you meet your team’s commitments. In practice, this is exactly what happens. It’s better a different team than yours gets punished for not delivering, even if it’s worse for the company.
Stop fooling yourself with feature-based roadmaps with specific timelines
There are cases where it makes sense to have features on your roadmap (e.g., in case of rebuilding your product or a fixed price contract with fixed scope and timeline) or when you’re working in a non-complex domain. But if you want to prioritize discovery, learning, and experimentation, having a roadmap with features and timelines will set you up to fail from the start.
The whole point of working in a complex domain is to work with what you do know, so you can figure out what you don’t know. Your plans and actions will be inadequate and never produce the desired results immediately. To move in the right direction, you need to adapt, rework, polish, and be flexible.
When you move beyond the isolation of your individual Scrum Team, even more flexibility is required. The complexity increases exponentially as the number of teams grow. The default response to uncertainty across teams is to fall back to more planning, analysis, and design.
Even though we know this approach already fails for single-team Scrum, somehow we fool ourselves it might work for multi-team Scrum. Over-analyzing with limited knowledge is an ineffective approach compared to swiftly responding together with all teams based on what you discover and learn.
Make sure different teams working on the same product have an overall roadmap or goal that indicates what is most important. Many companies have a single roadmap per team. Effectively this means you’re relinquishing control over what will be prioritized. Your teams will duke it out and fight for their turf, often at the expense of the company and without considering the grand scheme of things.
Embracing that you can’t and don’t know everything will always work better than sticking your head in the sand and pretending you know all there is to know.
As beautifully phrased in the Agile manifesto:
“Responding to change over following a plan.”
In a complex domain, you can only trust your plans (and roadmaps) to the extent they resemble reality. Which means you can’t trust them completely, ever. You can’t prevent that at some point, your initial thinking will disconnect from reality. No matter how much we talk, design, analyze or, coordinate, we’ll never be in complete control.
You can’t control the complexity of the real world, you can only learn how to swiftly deal with unforeseen obstacles as they present themselves.
