Create More Management Ease with Continuous Flow and Lower WIP: Aging First

Most managers I see feel a ton of pressure for delivery. The managers need to “deliver” more projects, products, and features. That pressure rolls down to the teams. Too often, the team hears, “Can you just do a little more?” That often leads to the so-called “quiet quitting” problem.

The problem isn't quiet quitting. The problem is that the feedback loops are too long because the WIP (Work in Progress) is too high.

In the image on the left, managers pressure everyone for faster delivery so the managers can change the portfolio or strategy. Managers pressure both the teams for faster blue feedback loops, and pressure the product people for faster red feedback loops. All to create faster green feedback loops.

Agility is About the Speed of Learning

However, agile approaches can help you learn faster, with various product minimums. When you learn faster, you know more about what the customer wants and how you work. Agile approaches can't help you go faster if you think you need to do it “all,” especially if the team and the PL don't make time for feedback as they create the product.

If the team tries to do more, they too often use shortcuts instead of technical excellence. They create more problems for themselves later, even if they can solve these problems now.

Shortcuts might give the appearance of “faster.” However, the team doesn't learn and without technical excellence, no one receives the expected value of the work.

All because the feedback loops are too long. The problems:

The WIP is too high.
Managers feel way too much pressure to deliver. They don't feel any ease at all.
Worse, the managers wonder why everything takes so long.

Little's Law explains all of this.

But managers don't have to create this system of work. They could feel the ease I feel in my product development. (See the series start: How I Manage My Product Development: Ease with Continuous Flow (Day 1).) Managers deserve a little respite from their pressure, too.

Let's start with how Little's Law affects the dynamics of product development.

See the Dynamics of Little's Law

Little's Law says that the average WIP divided by the average throughput gives you the average lead time. That average lead time is the green feedback loops above, in the first image in this post.

Right now, the teams take “too long” to deliver. That's the average lead time.

The longer teams take to deliver, the more pressure managers feel to have “better” plans. But, that pressure for more and better planning increases WIP, lowers throughput, and increases cycle time.

The more the teams plan, the less they finish work (because they're planning). Teams often start more work—which increases cycle time and lowers throughput. So while planning is useful, there's a limit to how much planning helps a team or managers.

The higher the WIP, the lower the throughput, and the higher the cycle time.

The lower the throughput, the longer everything takes.

Managers could look at WIP, cycle time, or throughput. But those measures belong to the teams. Managers can't really influence team measures except to say, “We don't need “all” of it, let's use how-little thinking.”

But managers have many other places to intervene in the system. Specifically, to use aging as a guide to create more ease everywhere.

Aging: How Old Is Your Work?

How relevant is your older work? Or the newer work?

When work is relevant, someone says, “Stop doing all that other work and focus on this.” (Sometimes, none of your work is relevant. That's a different problem from the problems in this post.)

If your work is older than 30-60 days, ask yourself the Zeroth question for the project portfolio:

Is this work (or decision) still valuable? Should we do this work at all?

That work includes decisions.

Managers deliver decisions. Teams deliver products. Let's not confuse the two. But management decisions often create more WIP for teams. That's why I like to monitor management decision cycle time.

If a manager has not yet made a decision and the decision is outstanding after more than 30 days, assume no one wants that work.

I wouldn't just drop that work on the floor. Instead, I create a parking lot, put that decision on the parking lot and move on to the next decision.

Which decision, you might ask? The next oldest or the newest? I would go to the next oldest decision, because if people are still waiting for the decision, and they haven't pinged me, is that decision still useful at all? Or review the Cost of Delay discussion in How Cycle Time and Cost of Delay Makes Product Development Decisions Easier (Day 2).

Since I want to discourage aging, I'll start with the oldest decisions and continue to the newest. Make one decision and make sure the relevant team knows that decision. Then, move to the next decision. Stop when I've made my decisions.

Too often, I can't make those decisions alone. I need my peer cohort.

Decide as a Management Cohort

What is the overarching goal for this management cohort? What does the organization need the managers to do? If every single manager has their own (subordinate) goals, the organization cannot succeed. (The organization can muddle on for a while, but they'll never achieve the greatness they could.) The management cohort needs to create a superior, overarching goal for the entire department, if not the organization. (See Practical Ways to Lead an Innovative Organization.)

Without a superior, overarching goal, the green feedback loops will always be too slow.

Now, with that goal, Cost of Delay makes these decisions much easier:

If the new work is more valuable, stop the old work.
If the old work is more valuable, stop creating new work.

I know, that sounds simple to say and so, so hard to do. That's why I only use Cost of Delay to make decisions these days. Nothing else, because if we can't capture more revenue, we don't get to keep working. (This is one of the reasons personal objectives make every decision much more difficult.)

So these are the first steps to create some ease for managers, deciding as a cohort:

Assess the age of each manager's decisions.
Start with the oldest work: Is this work still valuable? If so, put it on a candidate list to continue. If no, either kill the work or put it on a parking lot. Continue through all the work.
Make sure you don't have more work than teams to do the work. If so, put more work on the parking lot.

Yes, this looks a lot like a project portfolio for management decisions.

Add In Continuous Flow

Now, as teams complete this one piece of work, the management cohort can choose which one piece of work the teams will do next. That work might be a different project, more of a given feature set, or something else.

When managers reduce the aging of their decisions, they can choose how long to make decisions for. The shorter the timeframe for decisions, the more the managers can use continuous flow. That allows everyone to reduce their WIP. The lower the WIP, the higher the throughput. That eases the pressure on managers.

Using aging as your guide, start reducing decision-making WIP. That will allow you to reduce team-based and other organizational WIP.

That's just the first step.

I'm still working through my WIP (insert maniacal laughter), so the next post will be in “a while.” But that next post will be about how to plan for the longer term when you're using continuous flow to plan for the short-term.

The Series

Managers can create more ease in their work by exposing their Important and Urgent decisions. They can assess their cycle time, and manage which decisions to start and finish when. For periodic decisions, see if you can address fewer decisions more often. (I recommended rolling wave planning.) And measure your cycle time to understand your decisions.