Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Teams, Iterations , the Agile Product Owner, Backlog, User Stories and the Iteration Backlog the Release and Vision and Release Backlog. In this post, we’ll discuss the Roadmap, [callout 8] below.
For anyone following this series closely, you may have noticed a subtle shift at some point when the Roadmap icon (8) magically appeared behind the Vision (7). While I’ve been trying not to overload the Big Picture with unnecessary detail, it became clear during my explanations that the Roadmap is integral to the Big Picture and you can’t effectively explain enterprise agility without describing this key element.
When we described the Vision in the last blog post, it was presented as time-independent; the Vision is intended to provide a sense of the objectives of the product or system without any binding to time. This is appropriate as the objective is to communicate the gestalt of “what this thing is we are about to build” and overloading with timelines will likely derail the discussion of the “what”.
However, in order to set priorities and plan for implementation, we need an additional perspective that enhances the understanding. This is the purpose of the Roadmap. The Roadmap is not a particularly complicated thing, nor is the mechanical maintenance of it difficult. For example, a typical Roadmap might be communicated in a single graphic as follows:
The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set. While it is a simple thing mechanically to represent the Roadmap, figuring out the content is another matter entirely. The topic of what the team plans to ship and when can be a deep, fascinating and occasionally contentious topic in agile and we can’t cover it all here. However, the easiest way to think about the Roadmap is that it is an output, rather than an input to the Release Planning process. Fortunately, we covered Release Planning fairly extensively in the Release Planning blog series as well as in the Enterprise Agility Big Picture (6) The Release so there is some Roadmap guidance there for those who follow this Big Picture model.
But before you do all that clicking and reading, here are some summary guidelines for the role of the Roadmap in the context of the Pig Picture:
- The Roadmap is an output, rather than an input to the Release Planning Process
- The next release may be Internal or External. In either case, the dates and themes for the next release are fixed. The features are prioritized and variable.
- The Roadmap is a “plan of record” and is subject to change as development facts and customer needs change
- The teams generally commit to only the features in the next upcoming release. Releases beyond the next represent only the team’s current best estimate.
And perhaps the most important guidance is this:
Even within the next upcoming release and even though the team has committed to the objectives of the release, the feature set cannot be guaranteed. If it were, then you would have fixed scope-fixed time-fixed resources for an extended time period and that fails the agile acid test. However, it is a reasonable expectation that a team that has committed to the release will:
1) meet the date
2) meet the theme or objective, and
3) deliver most of the features, and certainly the highest priority ones with the requisite quality.
Doing anything less would be unprofessional and belie the power, discipline and accountability of our agile enterprise model. Moreover, it will eventually threaten our own empowerment, as failure to deliver will inevitably cause the implementation of various controls to “help us”!
That’s it for the Roadmap in the Big Picture. We’ll touch upon it again in our next post, the Agile Product Manager.