Sherry, a middle manager in a relatively small organization, said, “We can’t plan for an entire quarter at a time. Our managers need to change what they want more often than that. But I'd like to plan for a quarter at a time and I really don't want to ask people to multitask. What do I do?”
“How long can the managers commit to their decisions?” I asked.
“About a month. Sometimes, more. Sometimes less. But four weeks is a good number.”
I shrugged. “So don’t plan for more than four weeks at a time. You have options, to plan the next bit, but why should you plan for longer?”
“I thought I had to.”
“Nope. There's no such rule that everyone has to plan for a quarter. Especially not if your management can't commit to an entire quarter. How often do the teams release?”
“They can't release every day,” Sherry said, “but they can release at least once a week, sometimes twice.”
“So don't plan for any longer than a month. You have many more planning options this way. And as a benefit, the teams might learn to release faster.”
That's when we started to talk about her planning and replanning options: rolling wave planning and pull planning.
Rolling Wave Planning
I used to focus on rolling wave planning, where we always had a three- or four-week rolling wave of plans. See Create Successful Schedules: Three Tips to Rolling Wave Planning and the series that starts with Alternatives for Agile and Lean Roadmapping: Part 1, Think in Feature Sets. (There's plenty more about rolling wave planning on this blog.)
Here's the quick idea about rolling wave planning:
- A leader creates a four-week plan. The duration of the plan is the wave, here four weeks. (My plans were always firm for the first two weeks, and “squishy” for the last two weeks.)
- As the team completes one week, they add another week to the end and drop that first week, because the team completed the work.
- If you need to change anything in the squishy weeks, that's fine, because the team isn't ready for that work yet. The work past the first couple of weeks is squishy. (Not quite options, but not commitments.)
- Continue until the team finishes all the work.
Rolling-wave planning works because it forces the planners to focus on smaller chunks of value and what's valuable now.
But rolling wave planning isn't the only option. Sherry can pull work, instead of planning for a couple of weeks.
Pull Planning from Options
Sherry's organization appears to need to change everything the next time they plan. That's when I like an options list. See Three Planning Ideas to Support Your Future Decisions.
Here are ways to store those options:
- The parking lot, from a feature backlog or the project portfolio, depending on what you're planning.
- An unordered list.
- A ranked kanban board.
If we need change everything, I don't want to waste time ranking in advance. Instead, I much prefer a parking lot or an unordered list. The image above is ordered, but it has questions. The questions satisfy my need to avoid too-early decision-making.
Sherry saw the image at the top of this post and said, “Ah, I can use this to plan for the first couple of weeks. The black line and idea of the MVP will help people see we can replan any time we hit the black line.”
Exactly.
We discussed how much she needed to plan—did she need to plan even for two weeks? She—and the teams—were not happy with less planning, so she went with two weeks. But she could still focus on small chunks of value for now.
Make It Easy to Replan
Sherry used these ideas first for her project portfolio. Later, she used these ideas for the product roadmaps.
Her managers met once a month to re-evaluate the project portfolio. If a team finished their work early, she did not ask them to start another project. That would increase the organization's WIP (Work in Progress). Instead, she asked that team to work with any other team that still had not met their MVP. If every team had finished their MVPs, she asked the teams to collaborate on the next most valuable project.
The couple of times the teams had no obvious next project, they chose to finish their unfinished work: insufficient test automation and those irritating defects.
And, she asked all the teams who worked together to use these principles:
- Work in flow efficiency, collaborating as much as possible.
- That meant they might pair, but she requested that they swarm in pairs, or mob as a larger team. (See Pairing, Swarming, and Mobbing.)
Once the teams learned how to work like that, they became much more adaptable and flexible.
Sherry's happy with planning for a week or two, and then having options she can pull from. Her managers are too nervous to consider pull planning for everything, but so are the teams. She's able to use how little thinking, instead of how much thinking.
You don't have to plan for a quarter at a time—especially if your managers can't commit to those plans. Plan for a little less than the duration of time your management can commit to you. For Sherry, that was a couple of weeks, and then replan which work comes next. Avoid the waste of planning time when you know you will have to replan.