I’m working on the program management book, specifically on the release planning chapter. One of the problems I see in programs is that the organization/senior management/product manager wants a “commitment” for an entire quarter. Since they think in quarter-long roadmaps, that’s not unreasonable—from their perspective.
There is a problem with commitments and the need for planning for an entire quarter. This is legacy (waterfall) thinking. Committing is not what the company actually wants. Delivery is what the company wants. The more often you deliver, the more often you can change.
That means changing how often you release and replan.
Consider these challenges for a one-quarter commitment:
- Even if you have small stories, you might not be able to estimate perfectly. You might finish something in less time than you had planned. Do you want to take advantage of schedule advances?
- In the case of too-large stories, where you can’t easily provide a good estimate, (where you need a percent confidence or some other mechanism to explain risk,) you are (in my experience) likely to under-estimate.
- What if something changes mid-quarter, and you want more options or a change in what the feature teams can deliver? Do you want to wait until the end of a quarter to change the program’s direction?
If you “commit” on a shorter cadence, you can manage these problems. (I prefer the term replan.)
If you consider a no-more-than-one-monthly-duration “commit,” you can see the product evolve, provide feedback across the program, and change what you do at every month milestone. That’s better.
Here’s a novel idea: Don’t commit to anything at all. Use continuous planning.
If you look at the one-quarter roadmap, you can see I show three iterations worth of stories as MVPs. In my experience, that is at least one iteration too much look-ahead knowledge. I know very few teams who can see six weeks out. I know many teams who can see to the next iteration. I know a few teams who can see two iterations.
What does that mean for planning?
Do continuous planning with short stories. You can keep the 6-quarter roadmap. That’s fine. The roadmap is a wish list. Don’t commit to a one-quarter roadmap. If you need a commitment, commit to one iteration at a time. Or, in flow/kanban, commit to one story at a time.
That will encourage everyone to:
- Think small. Small stories, short iterations, asking every team to manage their WIP (work in progress) will help the entire program maintain momentum.
- See interdependencies. The smaller the features, the clearer the interdependencies are.
- Plan smaller things and plan for less time so you can reduce the planning load for the program. (I bet your planning for one iteration or two is much better and takes much less time than your one-quarter planning.)
- Use deliverable planning (“do these features”) in a rolling wave (continue to replan as teams deliver).
These ideas will help you see value more often in your program. When you release often and replan, you build trust as a program. Your managers might stop asking for “commits.”
If you keep the planning small, you don’t need to gather everyone in one big room once a quarter for release planning. If you do continuous planning, you might never need everyone in one room for planning. You might want everyone in one room for a kickoff or to help people see who is working on the program. That’s different than a big planning session, where people plan instead of deliver value.
If you are managing a program, what would it take for you to do continuous planning? What impediments can you see? What risks would you have planning this way?
Oh, and if you are on your way to agile and you use release trains, remember that the release train commits to a date, not scope and date.
Consider planning and replanning every week or two. What would it take for your program to do that?
