WIP limits and the queues you can't see

Work in software spends most of its life stationary.

That's the finding, every time, in every organisation I've mapped.

A change takes two days to write and nine days to arrive, and the seven-day difference isn't slack in anybody's calendar. It's the change sitting still. In a queue. While people are busy with other things.

Queues are invisible in a way that busy people are not.

Nobody's calendar shows "waiting." No status report says a pull request has been open since Tuesday.

The work is stopped and everyone is working. Exactly the configuration that makes an organisation feel productive and be slow.

Mapping it takes an afternoon

You don't need a tool.

Take five things that shipped recently and reconstruct, on a whiteboard, everything that happened between the decision and the customer.

For each step, two numbers: how long the work took, and how long it waited before the step began. That second column is what you're after, and it's the one nobody has ever written down.

The picture is almost always the same.

A handful of steps with real work in them, separated by gaps of one to four days each, and the gaps adding up to most of the elapsed time. Often it's the first time anybody in the room has seen the whole path, including the steps invented years ago for reasons nobody present can name.

Do it with the people who did the work. Not about them.

The numbers get uncomfortable, and the discomfort has to belong to everyone.

The four queues

Nearly every org has the same four, in roughly this order of expense.

Code review. Almost always the biggest, and it has a nasty property.

It's a queue between peers. Nobody has authority to push anything to the front, and everyone's own work is a legitimate reason to delay somebody else's.

Testing or QA sign-off, where it exists as a separate step. A batch queue by design, and batch queues are the worst kind, because everything waits for the slowest item in the batch.

Approval. Change advisory boards, security review, a director's sign-off, a release manager.

Each created after an incident. Each now taxing every change forever, including the thousands carrying none of the original risk.

Deploy. A release train, a weekly window, an environment only one team can provision.

Work that's finished and sitting. The most expensive inventory you can hold, because you've paid all the cost and received none of the value.

Every one has a fix, and none of the fixes are exotic.

Review: smaller changes, plus an agreement about response time. QA: move testing into the work rather than after it. Approval: risk-classify changes so the routine ninety percent never touch the process. Deploy: deploy continuously, and decouple release from deploy with flags.

One rule, not a system

Formal WIP limits work, in the sense that they produce the intended behaviour.

A number per column, enforced. My experience is that they get routed around inside about two months, because the limit is a rule imposed on a board rather than a shared understanding of why the queue hurts.

People split tickets. They create a "blocked" column that doesn't count. Or they move things without updating anything.

So I run one rule instead, and it's the only one I've found that survives.

Nobody starts new work while the review queue is red.

Red gets defined once, by the team, in a way that's visible without asking. More than a certain number of open pull requests. Or anything older than a day. Whichever they choose.

When it's red, the next thing you pick up is a review. Not a ticket.

That's it. It's a WIP limit in effect, since work in progress can only grow so far before the review queue backs up, and it's enforceable because it's one sentence and the state is visible on a screen.

Why it works where a formal system doesn't.

It points at a queue rather than at a person's workload, so it doesn't read as a productivity rule. It has an obvious action attached: go and review something. And it's self-correcting, because clearing the queue is exactly what makes the rule stop applying.

Code review is the queue to fix first

If you only attack one, attack this one, and attack it on latency rather than on quality.

The mechanism that matters most is size.

Review latency is a function of how intimidating the diff is, not of how busy the reviewer is. A forty-line change gets reviewed in the gap before a meeting. An eight-hundred-line change gets postponed until somebody has a clear afternoon, which is never, and when it finally happens the review is worse anyway because nobody can hold that much context at once.

Then a response-time agreement, made by the team rather than by you. A review within a working day, or say you can't.

The commitment is to respond, not necessarily to do it. Much easier promise to keep, and it removes the ambiguity that causes the delay.

Then make the queue visible somewhere people already look. A channel, a dashboard, anything, with age on it.

Most review delay isn't refusal. Nobody noticed.

And be specific about what review is for.

One that mixes correctness, architecture and style preferences takes three times as long and produces arguments. Style goes to the formatter. Architecture goes to a conversation held before the code was written. What's left is the part a human should be doing.

Blocked work is a queue with nobody watching it

The special case worth its own paragraph, because it hides in plain sight.

Every board has things marked blocked, and most organisations treat that as a state rather than an event.

Work sits blocked for eleven days. The thing it waited on was a decision anybody could have made in five minutes, if they'd known it was pending.

Two habits fix most of it.

Blocked items get an owner and a date, always, and the owner is whoever will unblock it rather than whoever is stuck. And anything blocked more than two days goes automatically onto the agenda of whatever weekly meeting has decision-makers in it, without needing to be raised.

Nobody needs a process for this.

They need somebody looking at the blocked column with actual attention once a week. Fifteen-minute job. Almost nobody does it.

The number to watch

Flow efficiency: active work time divided by total elapsed time. Most teams measuring it for the first time land between five and fifteen percent.

The number matters less than its direction.

Improving means the queues are shrinking. Flat while everyone works harder means you're pushing on the wrong part of the system, and the effort is going somewhere you can't see.