Capping the queue

The counterintuitive move

If review is the constraint, the correct response to a faster writing stage is to start fewer things. That sentence is correct, it is well supported by queueing theory, and it will be resisted by everyone who has ever been measured on activity.

The mechanism, restated: work in progress equals arrival rate times time in system. Hold the service rate fixed, raise the arrival rate, and time in system rises proportionally. Every extra item in flight makes every other item slower, including the one you most want finished.

What a limit looks like in practice

Per person: at most two open pull requests. When you have two and want to open a third, you must first get one merged, which means going and reviewing somebody else’s, or chasing yours through, or splitting it. The effort moves to the constraint automatically, without anybody having to decide it should.

Per team: a number on each column of the board. In review: five. In progress: eight. When a column is full, nothing enters it. The board stops being a list of everything anybody is doing and starts being a system with a shape.

Pull, not push. Nobody is assigned work. When you have capacity, you take the next item. This sounds like a small procedural difference and it is the whole mechanism: pushing work into a full system is how you get a full system.

Setting the number

There is no correct value and there is a good method for finding one.

Start at roughly your current average (count what is actually in flight today) and then lower it by one every couple of weeks until something hurts. What hurts first tells you where the real constraint is, which is the information you wanted.

If lowering the limit leaves people idle, that is a finding rather than a failure. It means your bottleneck is elsewhere, and the idle time is visible capacity you can move to it. Idle time that is visible is far more useful than idle time hidden inside a queue of half-finished work.

The conversation with a manager

This is the hard part, and the argument that works is arithmetic rather than philosophy.

We merge about 20 changes a week and we have 25 open. That is 1.25 weeks from opening to merged, and you can check it. If we open 40 a week and review capacity does not change, we merge 20 and the pile grows by 20 a week, for ever. We would show more activity and deliver the same amount, with worse review on all of it.

If we cap at 12 in flight, time in system drops to about 0.6 weeks. Same throughput, half the latency, and reviews get more attention because there are fewer of them waiting.

Two numbers, both from your own systems, both checkable. This works far better than any appeal to principle, because it makes a prediction and invites verification.

The follow-up question is always whether this means people will be idle. The honest answer is that they will be doing the work that actually moves delivery: reviewing, testing, pairing, deleting things, improving the pipeline. All of that is invisible on an activity dashboard and all of it is at the constraint.

Where it goes wrong

Limits without a rule for what to do when blocked just produce frustration. Write it down: when you cannot start something, you review, you help finish something, or you work on reducing the constraint. Not “start something else”.

Limits that ignore urgent work get abandoned in the first incident. Have an explicit expedite lane with a limit of one, and the rule that using it means something else stops.

Limits on a board nobody looks at are decoration. The limit has to be visible at the moment someone is about to break it.

Counting the wrong thing. If your limit is on tickets but the queue is in review, you have limited the wrong stage. Put the limit where the wait actually is, which you know from measuring stage times.

The deeper point

A limit on work in progress is a decision to make the constraint visible instead of hiding it inside a queue. That is uncomfortable, because a visible constraint is a thing somebody has to answer for, and a hidden one is just everybody being busy.

But you cannot elevate a constraint you cannot see, and a system with unlimited work in progress is a system that has chosen not to look at its own bottleneck. In a period when the stage in front of the bottleneck got several times faster, that choice became much more expensive than it was.