Agile Product Responsibility in the Enterprise, Part 3: Maintaining the Product Roadmap
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
My InformIT article "A Contemporary Framework for Agile Product Management in the Enterprise" described a framework for product management and roles for the Agile enterprise product owner and product manager. In the article, I suggested these Agile-specific responsibilities for the product manager:
- Own the vision and release backlog.
- Manage release content.
- Maintain the product roadmap.
- Build an effective product manager/product owner team.
In part 1 of this series, I described the first of these responsibilities: Owning the vision and release backlog. Part 2 discussed the issues involved in managing the release content. In this article, I'll describe the specifics of the third responsibility, maintaining the product roadmap.
So far, we've considered the product vision as being time-independent. This is appropriate because the objective is to communicate the gestalt of "this thing we're about to build," and overloading the vision with prospective timelines is likely to derail the discussion of what the "thing" actually is.
However, in order to set priorities and plan for implementation, we need an additional perspective—a product roadmap that provides a view we can use to communicate future objectives to our outside stakeholders. An Agile roadmap isn't 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 shown in Figure 1.
)
Figure 1 Sample graphic representing a product roadmap.
The roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set. While it's a simple thing to represent the roadmap mechanically, figuring out the content for anything beyond the next release is another matter entirely. The topic of what and when the team plans to ship can be fascinating and contentious in Agile. However, the easiest way to think about the roadmap is as an output, rather than an input to the release planning process:
- The dates and themes for the next release are fixed. The features are prioritized and variable.
- The teams can commit only to the features in the next upcoming release. Releases beyond the next represent only a best estimate.
The roadmap is a "plan of intent" and is subject to change as development facts, business context, and customer needs change. With respect to the upcoming release, perhaps the most important guidance is this statement:
Even though the team has committed to the objectives, and we have agreed that the feature set cannot be guaranteed, it is a reasonable expectation that the Agile teams will do the following:
- Meet the date.
- Accomplish the theme.
- Deliver most of the features, and certainly the highest-priority features, with the requisite quality.
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"!
Confidence and Commitments (Release Next, Next+1, and More)
With the enterprise release planning function, the objectives and prioritized feature set for "Release Next" should be a high-confidence plan of intent, at least for those Agile enterprises that have some initial degree of maturity. Being flippant for a second, it's often true that release "Next+1" has a pretty clear definition as well, if for no other reason than it usually must contain all the stuff that didn't fit in Release Next! After that, however, most bets are off, and the enterprise must rely on its portfolio-level Agile estimating and planning, assuming that such a degree of maturity actually exists within the enterprise.
In any case, it's important to keep any such future commitments abstract, so that the intent can be met under most normal circumstances. After all, if long-term commitments are fixed, then you have essentially reentered a waterfall model of fixed resources, fixed time, and fixed scope. Even worse, in so doing, the enterprise will lose its ability to adapt to change, which was the purpose of going Agile!