One of my clients was trying—valiantly—to make their quarterly planning sessions work. They prepared, getting the big hotel room. They had plenty of supplies. The planning even went well.
However, within two weeks, their plan had no relation to reality. That meant that for the next ten weeks, the product owners were “on their own.” And, because the product managers were out of the office so much, they had a terrible time deciding what to do to benefit the entire program.
These POs were smart. They knew what they needed to do for their own projects inside the big program. However, they didn’t have insight into what they could do when their products required change based on feedback and still provide value for the entire program. They needed more resilience than one quarter’s worth of planning could provide.
You might not have that particular problem. However, I have seen this problem:
The larger or more important the effort, the more feedback the teams need and the more the product owners need to replan to provide the most value to the effort.
You don’t need to be a program to have this problem. You could be a product owner such as the one I coached a year or so ago. He had a total of 12 people working in two teams all on one product. As they released value, they received feedback that guided this PO’s backlog creation.
The PO’s problem? He couldn’t predict more than about six weeks of work at a time. He needed more resilience in the project. His managers wanted more prediction.
Resilience in a project or program is why I’ve been recommending rolling wave planning or lean planning. These alternatives help people see minimum work in terms of feature sets, plan minimum feature sets or parts of feature sets, and replan the work when it makes sense to do so.
How much resilience and feedback does your project or program need? Does your roadmap look more like the changed-feature roadmap where features vary in value and arrival?
Here are ways to think about this question:
- Do you need to build or run experiments to learn? How long are those experiments?
- Do you need to validate business hypotheses to understand what your customers will and will not buy?
- Do you need to release small and then release to your entire customer base based on what you learned in the small release or to manage risks?
You might have more questions. These are all questions that suggest larger planning is not as helpful. As I said in Part 1, you might find that the discussions from larger planning are helpful. However, the planning itself might not be worth it because you need to replan.
I don’t know of a project or program longer than a few weeks that doesn’t need feedback. In my experience, all projects/programs need feedback. Maybe your project or program is different.
Different projects/programs require different amounts of resilience. If you are using agile approaches to see the product progress, but you can predict everything because you already know how to do this work, terrific. Plan for an entire quarter.
However, if you are more like the projects and programs I see, consider shorter planning and replanning alternatives.
My next post is about how to replan with a Product Value team for a project or a program. I’ll address the managers-wanting-prediction problem after that
| Reference: | Alternatives for Agile and Lean Roadmapping: Part 4, Resilience, Prediction, & Feedback from our JCG partner Johanna Rothman at the Managing Product Development blog. |
