In Part 1, I wrote about thinking in feature sets so everyone could see smaller chunks of work. (If you can see them, you might be able to plan for smaller and deliver smaller.)
In Part 2, I suggested smaller rolling waves than an entire quarter (two months, or preferably one month) so people could see what they might deliver as those small chunks. I suggested changing your thinking because of what I’ve seen too much of: pressure for teams to do more, and the need to change what the teams do.
It’s tempting when people work in iterations to “push” more work onto the teams. Iterations don’t have to be that way, but it’s often difficult for managers to understand why everything takes “so long.” Couple that pressure for changing what the teams commit to, and I’ve seen more failures with quarter-based planning than I’ve seen successes.
This is human nature, not anyone’s fault. Is there a way to make it easier to do the right thing? Possibly. Consider lean roadmapping where we intend to pull work instead of iteration-based roadmapping where it’s too easy to push work.
This roadmap looks a little different because it’s scope-based as opposed to time-based, and it shows our uncertainty.
I specifically think about releases as MMF (Minimum Marketable Features). Notice that everything above the black line says, “Enough for a release.” The idea is that if we have enough for a release the second week of a quarter, we release. If you prefer to release on a cadence, go ahead. However, you might be able to release on a more frequent basis if you release when you have enough.
The big picture roadmap is not sufficient for detailed planning. That’s where the one-quarter roadmap is useful. (If you are on a short project, you might need month-based roadmaps, not quarter-based roadmaps.)
I specifically use the term MVP, Minimum Viable Product, to help people realize it is the minimum we could release to validate a business hypothesis.
Since we still have above the line (what we want to accomplish) and below the line (what we would like to accomplish, knowing what we know now), we know we have a chance to rethink everything below the line (inside a quarter and for more quarters).
If you want to try this, make sure your MVPs are minimum. You might want to use MVEs in places, to learn quickly and decide what to do next.
I’ve shown the planning on month boundaries because managers often want to see what they can “depend” on for a given month. (I really need to write about ambiguity in management!) In my experience, the less we commit to, the more flexible and resilient the project or program is, and the better the outcome. We can use agile approaches to change what we do and when.
I’ll write about how much resilience your project or program needs next.
| Reference: | Alternatives for Agile and Lean Roadmapping: Part 3, Flow-Based Roadmapping from our JCG partner Johanna Rothman at the Managing Product Development blog. |
