“You aren’t doing Agile yet?”
If your firm is still utilizing waterfall for product development, you’ve likely heard some variation of this question. Probably when you dropped a “PRD” reference while in mixed company (that’s a “Product Requirements Document” for the newbies). While the waterfall development has served many companies well over the years, Agile is now indeed all the rage. There have been decades of evangelism and countless books, keynotes, and blog posts. Most organizations that haven’t already taken the plunge are finally indoctrinating into Agile. But at this late date, that Waterfall to Agile transition might feel completely overwhelming.
The Waterfall to Agile Transition
There were reasons your company held out this long. It’s not just because you’re afraid to implement new ways of doing things. Any change is hard, and the Waterfall to Agile transition can be downright disrupting. It impacts many elements of product planning, team dynamics, operations, and delivery. If the consensus was that waterfall worked, why bother shaking things up?
Yet it’s tough to argue with the results. Agile organizations can be far more nimble in their response to changing market conditions. They ship products (or at least incremental updates) far more often. This process delivers additional value to customers faster and more frequently. They can experiment more readily, testing, and switching things up to commit minimum resources for maximum rewards. They’re far more productive and efficient, limiting time spent on projects that don’t pan out and net positive results.
Your mileage may vary
However, not every company that claims to be Agile is. Even if they’ve adopted some of the manifesto’s tenets and practices, plenty limit Agile to product development. They still using plodding, top-down processes to set strategies and make business decisions.
But the fact that engineering teams can crank out sprints before the executive team pushes the entire organization into an Agile transformation shows one of Agile’s strengths. Agile can be whatever you want or need it to be.
It can be refreshing to hear how to utilize aspects of Agile without subscribing to a rigid orthodoxy of compliance. It highlights the fact that Agile can be adopted gradually. Just like a product roadmap illustrates the incremental steps to achieve a product vision, Agile builds up over time.
Agile and your roadmap
One aspect that may confuse Waterfall veterans transitioning to Agile is how it impacts product roadmaps. Roadmaps carefully plot out the future and have historically included particular items and dates. How can they co-exist with Agile?
When done correctly, roadmaps can not only survive an Agile transition, but they can thrive. Roadmaps can aid the Waterfall to Agile transition itself while providing much-needed guideposts once the change is complete. They can also help ease the uncertainty that Agile may introduce.
The short and the long of it
No one can predict the future, but product roadmaps in a waterfall world make a valiant effort to do so. They plot out release after release, feature after function, complete with ship dates and version numbers.
But spelling out everything that will happen for the next 18-24 months doesn’t work in an Agile world. By definition, things will be more fluid. Determining implementation details won’t occur until much closer to when the work happens.
For your roadmap to maintain its relevance and relative accuracy, you must adjust your planning cycle. Let go of trying to chart every detail for much longer than six months. No matter how carefully you plan, things will change. Your specificity will only cause drama and disappointment.
Instead, think of your roadmap as having two tiers of granularity. The long view will still stretch out into the future and remain high level. It features strategic goals and aspects of the product vision. But it will lack specific dates and individual pieces of functionality.
Quarters replace months. Features replace themes, and it will all still serve an important purpose. Stakeholders, engineering, sales, and customers still must see where things are heading. They need to know what objectives are targeted for completion when. But it will remain vague and opaque until the implementation is imminent. This vagueness allows the details to be determined later, enabling the incorporation of more recent data and strategic updates.
However, the more immediate chunk of your roadmap can still be chock full of details and specifics. Agile doesn’t mean developers wake up every morning and code what they feel like. There will always be more concrete and clear-cut deliverables for the near-term releases. These can and should be on the roadmap to keep everyone aligned and communicate expectations.
Letting go via empowerment
Agile and micromanagement don’t co-exist easily. To truly tap into the benefits of transitioning to Agile from Waterfall, teams need some freedom and space to build things as they see fit. This freedom doesn’t mean they can make anything they want, but it gives them lots of room to build it how they want.
Working with Agile teams is a significant shift for product managers. But allowing smaller teams to flourish and ship software independently is the goal. Product managers can feel more comfortable loosening their grip on that process with a reliable roadmap. When the whole team understands the goals and intentions of the initiatives they’re working on, it facilitates unconstrained yet strategically aligned output.
A single source of truth
In a fluid, dynamic environment, it’s easy to miss the forest for the trees. In this case, sprints are trees, but your roadmap is the forest. While developers build what’s directly in front of them, everyone can keep an eye on the big picture using a roadmap that encompasses it all.
Whenever there’s a question about why you’re building something, the roadmap provides an answer. If there are concerns as to how an item fits into the bigger picture, the roadmap supplies that context. When people want to know when these sprints will add up to something big, the roadmap shows them the way.
But for a roadmap to be the system of record for the organization, a few things must happen. First, there must be only one roadmap per team. There might be different versions for different audiences, but they’re all building off an identical starting point. This is where a tool that supports custom views comes in handy. Tools avoid version control issues from blurring a unified understanding of the strategy and vision.
Regular and frequent updates are also a must. While things occasionally change in a waterfall environment, it’s far more common when using Agile. Everyone should have access to the “latest and greatest” to ensure alignment. Changes and updates should communicate out with frequent reviews.
Finally, don’t allow the Waterfall to Agile transition to confuse the pecking order. Product management still owns the product roadmap. Although product roadmapping is collaborative, PMs are still ultimately responsible.
Embrace the Waterfall to Agile Transition Journey
Switching from Waterfall to Agile is usually a bumpy transition. Your organization won’t get everything right from the beginning. This mindset requires everyone to embrace the principles of Agile and take an iterative approach.
So start small, adjust as you go, and set realistic goals and expectations. Celebrate the successes, milestones, and achievements along the way. You can even create a roadmap for the transition itself, just like you would for any other major initiative.
Once your transition is complete, it’s time to make the most of what Agile has to offer.
