How to Reduce Planning, Deliver More, and Surprisingly, Reduce Pressure

In my first post, Why We Have Too Much Pressure and Planning & Too Little Delivery, I discussed the issue of too much planning and how that reduced delivery. In this post, I'll address how to increase delivery by planning less.

(I have a draft post of the system view of how too much planning reduces throughput. Let me know if you want to see that.)

Here's what the product leader can do to start.

Start with Product Strategy and Reasonable Tactics

I alluded to what product leaders can do in the previous post:

Explain the overarching product goal (product strategy) to the team. If there isn't an overarching goal, define that goal via the product strategy.
Rank order the work so the team limits its WIP and only works on the highest-rank work. Teams stop working according to each person's capability. Instead, they collaborate on this limited WIP.
Right-size the stories and collaborate so the team always finishes what it starts and does not start more work.

If you have component teams instead of a cross-functional team, use the daily check-in idea in Three Tips to Focus to Deliver Better Products Faster.

These tactics allow the team to start delivering faster and reduce its WIP.

Now, it's time to change how you plan. If your organization prefers time-focused plans, you can use rolling wave planning.

Start with Rolling Wave Plans Based on Time

(I've written about rolling wave planning in these books: Manage It!, Agile and Lean Program Management, Create Your Successful Agile Project, and a little in Project Lifecycles. Also in these newsletter and blog posts: Create Successful Schedules: Three Tips to Rolling Wave Planning, and Starting With Rolling Wave Planning.)

The idea behind a rolling wave plan is simple in concept: Only plan for as long as you are willing to waste. That's the same principle as limiting the time in an iteration-based approach, such as Scrum.

Time-based rolling waves depend on being able to rank order the work for at least a week, often two weeks at a time. A few of us can rank-order work for a month. Very few of us can see all the possible work and rank order it for longer than that. That's why rolling wave planning works.

Notice that I said “Rank” and not “prioritize.”

If you cannot rank work for at least two or three weeks at a time, consider pull-planning, as in the next section. You are not a bad person or a bad team. You are acknowledging the limits of your knowledge and the (lack of) predictability of your environment.

The Details of How to Plan with a Rolling Wave

Here's how rolling wave plans work:

As a team, choose the duration of your wave. How far can you see and rank-order the work? I normally recommend teams start with a three- to four-week wave.
Plan the details—rank the work items—for the first three weeks. Do you know what's in the fourth week? If so, add them. You now have a four-week plan.
Examine your plan. How much confidence do you have in that plan? When I do this with teams, they often are unsure about what goes into the third or fourth weeks. If you do not know what goes into those later weeks, do not worry and DO NOT PLAN FOR MORE WORK. If you do know what you want, add the one or two items you know you want in either of those third or fourth weeks, and leave it. The rolling wave means you get to refine the plan.
Start the work. As the team completes the first week, examine the team's cycle time, the time it takes the team to release an increment of value. Now, what is the next most valuable chunk of work? If that is not within the team's cycle time, see if you can right-size that work. Remember, the team only works on these ranked items as a team. No other work. While cycle time should account for various delays, if your team also has to manage production support or other interrupting work, reduce the number of items you plan for.
Now, using the team's cycle time and what is most valuable, ask yourself:
1. Do you need to replan any of the second, third, or fourth weeks based on what the team completed and their cycle time?
2. If so, replan those weeks. If not, that's great.
As the team completes one week of work, the team adds a new week and adds ranked items there. Now, you always have a three- to four-week plan of achievable work.

Will you have hiccups? Of course. That's because this is push-planning based on time. But those hiccups only affect this bit of planning, this wave, not an entire 18 months of “plan.”

Note: ALWAYS, ALWAYS, ALWAYS demo what you finish. Also, RELEASE what you finish. (And retrospect for the team's learning.)

The demos build internal trust. The releases build customer-based trust. All that trust will reduce the pressure on everyone.

You have alternatives, such as the rolling wave pull-planning, plans based on scope.

Consider Rolling Wave Plans Based on Scope (Pull)

I used to use one-week rolling wave plans in my business. I would plan for a week and list just one rank-ordered item each day.

Then, I had to balance more and more competing pulls on my time. My “week” plans were nonsense by Tuesday afternoon. (Most of these were good pulls, such as new clients wanting proposals, a new article, or my desire to complete another book. All that good stuff.)

Several years ago, I moved exclusively to pull planning. Here's what I do:

Create goals for this year. (I often have a combination of product work in the form of books, blog posts, articles, and workshops.) Your team might have a product strategy you can use as an overarching goal. If your team is supposed to work on several things “at once,” such as product development and production support, clarify the guidelines your team will use to decide what to do when.
Develop a list of options you want to complete “soon.”
Decide which one of those options is first. Rank-order those remaining options based on what you know now. Select and complete that first option. Measure your cycle time.
Choose the next most valuable thing. The team works on that. Measure your cycle time. Depending on your team size, you might be able to work on two or three options simultaneously. But, if you have interrupting work, I prefer that someone or a couple of someones have some slack to manage those interruptions.
As the team completes their work, demo and release. (And retrospect for the team's learning.)
Then, choose the next option by value. Continue measuring cycle time, so you have some predictability and can choose if you want to change how you work.

Always select options by value. And the more the team demos and releases, the more trust they build and the less pressure they feel.

The Details of How to Pull-Plan by Scope

Here's a one-month rolling wave plan for pull planning. The product leader and the team decide what the MVP is. That MVP might contain several stories from several feature sets. It all depends on the value the customer needs.

Now, see that big black line under the MVP? When the team needs more work, they pull work from under that line.

My “rules” for pull planning are:

How little can we plan to create that MVP?
As we complete that MVP, how can we add/subtract/change what's under the big black line?
How often can we learn, so we can re-rank the work under that big black line? How can we create options that allow us to make progress, but do not create fake certainty?

Now, I don't actually plan for a month at a time. I have a continual plan that allows me to change what I do every single day. I focus on overarching goals and options.

That means I might not know what an MVP is until I build from my options. Yes, I sometimes build up my MVPs from doing the work.

In push-planning we define the MVPs. That's often useful. But sometimes, it's not. We need to learn as we go. That's why I find pull-planning so much more valuable for me.

When I explain this to my clients, many managers go nutso. Then I explain how almost everyone does this in their personal lives.

Many of us set milestones or achievements and then plan. That means we start with a goal and create options. For example, if I want to take a vacation at the end of August or early September, I will set aside time in my calendar so I don't book any work then. (That's the first most valuable outcome I can create.)

Then, I re-examine that goal during the year. When do I have to choose where to go? Where to stay? While some of you can be very flexible, I require more planning. (By my personal nature and with my need for handicapped accessibility.)

But even I never finish planning my August vacation in February or March—that's way too early to commit to a plan. I wait for more information before I finalize plans. On the other hand, I probably have to complete my vacation planning earlier than some of you because there is limited availability of handicapped accessible locations, etc. I don't want to miss my vacation because I planned too late. Nor do I want to cut off possibilities because I planned so much in advance.

That's the essence of scope-based rolling wave planning. What's the first valuable thing to do? What are the other options we have for the rest of our work?

(See How We Can Stop Confusing Long-Term Goals with Short-Term Plans for more details.)

Effective planning means we don't try to plan more than we can see. “How little” thinking helps me with that.

Always Consider “How Little” You Can Plan

I first discussed the idea of “how little” in Manage It! Your Guide to Modern, Pragmatic Project Management. Since I live by that idea in my work, that idea of how little is also in all my other books.

The how little idea is this: How little can we do before we start the work to see what our reality is? Reality means we have some idea of how this team works, and how fast we can deliver something useful. I ask how little questions for everything:

How little up-front planning for a project?
How little organization-wide planning for anything?
How little for the project charter, any kind of team-based workshop such as requirements, architecture, design, etc.

How little is a forcing function to start the work to see what we can and cannot do within our various constraints.

That works for the planning time, too.

Now, how does this release pressure?

Release Pressure With Visible Progress

The more planning, the more WIP (across the organization). And the more planning at all levels, the more WIP at all levels. That slows our progress (lower throughput).

The more often a team demos and releases, the more they show visible progress. And the more they build trust.

Less planning allows a team to progress for a short time. More planning impedes their progress. Less planning means we change small plans, not larger plans. The larger the plan, the more implications for changing those plans.

Small plans that we can readjust in the moment release pressure and allow the teams and everyone else to make progress.

The Series:

Note: If you want to see the system view of pressure and planning, let me know.