How Scrum Teams Can Overcome the Roadmap Trap
Feature roadmaps lead to poor outcomes, while an outcome-oriented roadmap enables teams to excel.
Feature roadmaps lead to poor outcomes, while an outcome-oriented roadmap enables teams to excel.
A critical issue disturbs me. Most companies believe to be agile, and they use frameworks like Scrum, Kanban, and LeSS. However, every quarter the management board decides what will be part of the next roadmap. Such roadmaps mainly define solutions to implement instead of goals to pursue.
All teams are surprised once they become familiar with the roadmap. Sadly, the management board rarely collaborates with the teams to craft the roadmap. Yet, they insist on getting a commitment from the team.
Without a feeling of ownership, commitment is unreachable.
Let me share with you why traditional roadmaps don’t work and how you can enable Scrum Teams to thrive by defining objectives to pursue. Hopefully, after reading this text, you will understand how to rock with roadmaps.
Why Most Roadmaps Block Scrum Teams From Being Agile
From my experience, most roadmaps lead Scrum Teams to produce poor results because it blocks them from learning. The feature-roadmap is an anti-pattern; let’s have a closer look at the Scrum Guide to understand why.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
Scrum aims to solve complex problems empirically. But once the roadmap defines features to implement, how can the Scrum Team inspect and adapt? In such situations, Scrum Teams are powerless, and the result will be no more than mediocre.
The most common issues with roadmaps are:
Definition without the Scrum Team: The company's leadership defines what is necessary to do next. But they generally don’t involve the ones who work on the product to craft the roadmap. The resulting roadmap gets thrown over the fence to the Scrum Teams.
Pre-baked solutions: in combination with the previous problem, executives define solutions to implement instead of problems to solve. For example, implement a recommendation feature to bring new customers organically.
Timeline oriented: beyond defining which solution to implement, the deadline is written in stone. The Scrum Team has to run to match the expectations and deliver on the executives’ promises.
“The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process.”
― Marty Cagan, INSPIRED: How to Create Tech Products Customers Love
What Are the Results of Most Roadmaps
I’ve been in many situations where roadmaps were the worst nightmare of the teams. We had no choice but to transform our roles in the wrong way:
Product Owners became requirement keepers instead of value maximizers.
Scrum Master couldn’t do much but to convert into a project manager.
Developers didn’t have any chance to solve the problem the best way possible. They only knew the solution they had to implement.
To put it simply:
Without the freedom to explore how to reach the desired outcome, Scrum Teams will never be able to maximize the product value.
Unfortunately, most roadmaps focus on the what and when. Some examples of bad roadmaps are:
The referral program is implemented by the end of Q1 2021.
Chatbot is implemented by the end of Q1 2021.
Ratings & Review is implemented by the end of Q2 2021.
With such roadmap items, Scrum Teams will lack ownership. The team has no chance but to focus on the output instead of the outcome. Each item mentioned before may generate business and user value if the solutions are adequate for the end-users. But how do you know it without validating the assumptions?
“If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away“ — Linus Pauling
Many companies perceive technology as a means to an end. Executives are unwilling to empower Scrum Teams to decide how to solve the problems or benefit from the opportunities. That’s why the executives make decisions on behalf of the Scrum Team. However, we live in the digital era; technology is no longer a support area; technology is the business. If companies want to remain competitive, it’s time to empower the Scrum Teams.
Roadmaps like this ensure powerless Scrum Teams, high employee turn-over rate, and ultimately poor business results. Ironically, after mediocre results, executives end up saying, “Scrum doesn’t work for us.”
Now that I’ve shared some common problems, I’d like to share how you could avoid such scenarios.
Define Meaningful Goals
I have a confession to make; I hate roadmaps. From my experience, they neither help Scrum Teams nor motivate them. Objective Key Result is my alternative to roadmaps. I learned that establishing well-thought objectives and critical results lead to better results than roadmaps.
“Leaders must get across the why as well as the what. Their people need more than milestones for motivation. They are thirsting for meaning, to understand how their goals relate to the mission.”
― John Doerr, Measure What Matters
OKRs represent a technique used by many huge businesses like Google, Intel, and many others. Although it’s straightforward to understand, it’s easy to fall into pitfalls. I’ve had great and horrible experiences with OKR; I’d like to share with you the great ones:
Objective: the company leadership defines a set of goals to pursue. For example: reduce the customer acquisition cost to a sustainable level.
Key Result: the Scrum Teams break the objective down into actionable key results. The team defines what and when. For example: create a new customer acquisition channel 30% cheaper than the current average by the end of Q1 2021.
Ownership is the key to ensure OKRs work as expected. The leadership sets the direction, and the Scrum Teams take the problems to solve and define actions to tackle. With OKRs, Scrum Teams receive problems to solve, and they have the freedom to experiment with different solutions and find what works best.
“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.” — General George S. Patton, Jr. General”
What Not to Do With OKRs
Be careful! OKRs are not a silver bullet. It’s also easy to fall into pitfalls and results as bad as the traditional roadmaps. After many disappointments with OKRs, I’ve learned what NOT to do to ensure the promised benefits:
Objectives focused on the output: if the leadership defines objectives as solutions to implement, the Scrum Team has no chance but to fall into the feature factory anti-pattern.
Key Results defined without the team: executives set the what and when without involving the team responsible for it. This scenario brings a massive issue because the team will have no accountability to the key result.
Conflicting objectives: meaningful goals empower the teams to collaborate and solve real problems while conflicting objectives lead the team in opposite directions. Without collaboration, teams will inevitably fail.
Individual goals: setting goals on the personal level will hurt the collaboration level inside the team. The secret is to keep as simple as possible; the team should know where to focus instead of worrying about achieving arbitrary individual goals.
Final Thoughts
I confess I am a great fan of OKRs because they helped me escape from many dreadful situations. But it doesn’t matter what technique you use. For me, the following crucial aspects need to be covered:
Empowerment: executives have to empower the Scrum Teams. Otherwise, the team falls in a vicious circle, building solutions nobody needs.
Best usage of the knowledge: the team's skillset has to be better used. Executives should lead the team instead of telling them what to do. Scrum Teams should find ways to achieve the desired outcome instead of implementing solutions defined by somebody else.
Simplicity: it’s never about a complicated way of organizing the work. It’s all about defining a clear goal to pursue. More objectives will ensure the team produces less outcome. Successful companies focus on avoiding distractions so that the team has the needed space to work on what matters the most.
“Think Big but Start Small” — Google’s 8 pillars of innovation
Do you want to write for Serious Scrum or seriously discuss Scrum?