Continuous Agile Program Planning: Think Big, Plan Small

It seems as if the larger the agile program, the bigger the planning. Many organizations try to plan for an entire quarter at a time. They bring everyone on the program together in a large room (often a hotel ballroom) and attempt to plan the next quarter’s work.

That kind of planning works for some programs; it’s expensive in terms of time and travel. When all those people need to travel to one location, they don’t spend time working on the actual product when they are all together. They plan instead of delivering functionality.

Granted, there are other benefits when people get together in one location. They learn to work with each other. They also take a longer-term perspective on the program’s goals. I’m a fan of people learning to work together and planning.

However, the programs I’ve worked on or consulted to simply could not depend on an entire quarter’s worth of work being stable. More often, everyone would plan and return to their offices. A week or two later, something happened and the quarter’s plans were at risk.

What can you do? Instead of big, discontinuous planning, consider small continuous planning.

How Little Can You Plan? 
When you plan for a quarter, you might feel as if you’re asking, “How much can we plan now?” Instead of how much, consider asking, “How little can we plan?”

I like to think about releasing something at least as often as every month. I might have to release internally—not to customers—and that internal release still provides the program feedback. To plan small, I like thinking about both the big picture and small picture of what we want to release, and when. This picture is the big picture roadmap. The big picture helps me—and the entire program—know where we’re headed:

Many organizations use a several-quarter roadmap to plan what they want to release to the customers. In the several-quarter roadmap, you have the big ideas, but not the details of what you could release.

The big picture roadmap is useful for strategic product planning—what the program will deliver as releases, and when. However, the big picture roadmap is insufficient for the teams to know what to deliver when, or to uncover interdependencies. This is why I also use a small picture roadmap (maximum size of one quarter) to see the deliverables we hope the teams can deliver:

In this one-quarter roadmap—which is still a wish list—you can see the deliverables. Not all features are equal. Some features are larger than others. Some are more important—we might want to deliver one small feature from a feature set and then move to other features in one iteration, certainly in one month. Take a look at the “Text Transfer Part 1.” Those features take longer than one iteration to complete—the team doing text transfer thinks they will take two iterations.

The nice thing about agile is our ability to change what we want to do based on what the teams deliver and what the customers need. That’s why I like to use rolling wave, deliverable-based planning to plan small (and re-plan).

Consider Your Rolling Wave
If you were a successful project or program manager before agile, I suspect you created frequent deliverables that allowed everyone to see the product as it evolved. In my program management experience, we could plan for about a month’s worth of work. We needed at least a couple of weeks for the teams to deliver value so we could see how the product was growing. We could use that information to see what we needed next.

Here’s what a rolling wave plan looks like when you use the small picture as guidance to inform the rolling wave planning:

The first month is clear because that’s our plan. The next month is slightly grayed out to indicate it’s still a wish list. After the first two-week iteration, your roadmap might look like this, where the product owners moved the “Text Transfer Part 1” in by an iteration, and moved out the “Secure Login, New ID” by an iteration. Note that the finished work is now white, not colored:

I wouldn’t expect many changes in the beginning of a program (or a quarter, if you plan quarterly) because we need a walking skeleton of a working product. Once we have that walking skeleton, I see many changes in the middle and the end of a program.

Facilitate Smaller Planning
You might wonder about the role of the agile program manager in all this planning and re-planning. The product owners in some form do all the planning for the program and the feature area backlogs. Instead of deciding what deliverables the teams should do and when, the agile program manager facilitates smaller planning. The program manager serves the product owners by helping them realize when they can plan less and re-plan more. I’ve done this in these ways:

  • Nudging the product owners to remind them
  • Creating program milestones to create a shorter cadence of planning
  • Use a risk list to prompt less planning at one time and a more frequent cadence of planning

You might have other ways of doing this.

Serve the Entire Program with More Frequent and Smaller Deliverables
The agile program manager is the servant leader for the entire program. The more often the teams deliver finished value, the more feedback the teams get for their work—and the more feedback the product owners and product managers get for their planning. What kind of planning fits for your program? How small can the deliverables be, and how often can the product owners re-plan to better the overall product?

Agile program managers no longer do the product milestone planning. Instead, they help the program by creating program milestones that facilitate shorter planning horizons as they assess and manage their program’s risks. How little planning can you do, and how often can you do it?

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: