Applying WIP constraints: cap the queue, cap the delay

Limit the amount of work-in-process to control cycle time and flow.

By Little's Law, cycle time is WIP divided by throughput, so capping WIP caps the average cycle time. Queueing math shows the price is small: a limit at about twice the average unconstrained queue cuts the worst queues and the long cycle times while rejecting only a percent or two of demand.

WIP constraints force the rate of starting work to match the rate of finishing it.

When a downstream stage is full, upstream cannot push more into it, so the system admits work only as fast as it completes work. Without the constraint, a fast upstream stage keeps feeding a slower one and the difference silently becomes a queue.

Use a global constraint on total WIP when the bottleneck is predictable and permanent.

Theory of Constraints' drum-buffer-rope releases new work only as the bottleneck finishes it, capping the whole line's WIP with one simple rule. It works well in a factory with a stable bottleneck; in product development the bottleneck moves with the work mix, so a single global cap reacts slowly.

Where you can, constrain the WIP of each local pool instead of only the total.

A kanban limit at every hand-off (like TCP's window at every connection) stops the stage just upstream of a jam within one item, and the back-pressure propagates step by step. Local limits react faster and need no knowledge of where the bottleneck currently is.

Use a WIP range, not a single number, to decouple the batch sizes of adjacent processes.

If design hands work over in batches of five and test consumes them in batches of three, a fixed WIP target can never be met exactly. Let WIP float between an upper and lower bound so each process can use its own economic batch size while the total stays controlled.

When WIP reaches its upper limit, block all new demand until it falls.

The blocked work does not vanish; it waits outside the system in a cheap, uncommitted state (a backlog nobody has started, a request not yet accepted). This is the simplest response and the one a kanban card or a full TCP window applies automatically.

When WIP is too high, kill the lowest-value work in process.

Money already spent is a sunk cost; the question is whether the remaining work is worth its remaining cost plus the delay it imposes on everything behind it. A queue crisis is the moment to cancel the marginal projects that should have been cancelled anyway.

Reduce WIP by shedding non-essential requirements when the queue is high.

Cutting a feature from every item in the queue reduces the work content of the whole queue at once. Decide in advance which requirements are expendable so you can drop them quickly, the way a release train drops the stories that don't make the cut.

Apply extra resources to an emerging queue quickly, while it is still small.

Queues grow and drain asymmetrically: a little extra capacity early prevents a big queue, while the same capacity added late needs a long time to drain it. Speed of response matters more than the size of the response.

Use part-time resources on high-variability work so they can surge when a queue forms.

Someone loaded at 50% on a project can jump to 100% the day a queue appears, with no ramp-up because they already know the work. A full-time person already at 100% has no surge capacity at all.

Pull high-powered experts onto emerging bottlenecks.

A senior expert can clear in days a problem that would take a team weeks, so keep your best people lightly loaded and on call for queue emergencies rather than buried in routine work they would be fully utilized by.

Develop people who are deep in one specialty and broad across many.

A T-shaped engineer adds value on their own specialty and can still help usefully wherever a queue appears. Pure specialists are efficient but cannot move; pure generalists move but lack depth.

Cross-train people at adjacent processes so they can absorb each other's queues.

The most useful overlap is with the stage next door: a developer who can write and run tests can help when the test queue grows, and the hand-off between them gets better too.

Change the mix of work released upstream to regulate the queue at a bottleneck.

When the test queue is high, start the jobs that need little testing and hold the test-heavy ones; when it is low, do the reverse. The total work is unchanged, but the bottleneck's load is smoothed by sequencing upstream work.

Watch the age of items in WIP; the outliers carry the problem.

An average cycle time hides the few jobs that are stuck. Tracking the age of every item in process exposes them early, because an item that has been in a stage far longer than usual is almost always blocked, not just slow.

Have a pre-planned escalation process for items that exceed an age limit.

Decide in advance who gets told and what happens (more people, an expert, a decision from management) when a job crosses the aging threshold, so the response is automatic instead of negotiated each time.

Throttle demand gradually as the queue approaches its limit instead of slamming it shut at the limit.

Internet routers using random early detection drop a growing fraction of packets as the queue rises, so senders slow down before the buffer fills. Gradual throttling avoids the oscillation of on/off blocking and keeps the queue short.

Give different classes of work different WIP limits and priorities according to their cost of delay.

A single queue treats a high-cost-of-delay expedite like routine work. Separate workstreams with their own WIP constraints and priority give fast service to the urgent class, as Internet DiffServ does for voice versus email traffic.

Adjust WIP constraints as the capacity of the system changes.

TCP grows its window slowly while things flow and cuts it sharply at the first sign of congestion, constantly tracking the capacity it can actually get. A fixed WIP limit set for last quarter's team is too high when people leave and too low when they join.

Prevent individual work items from expanding without limit.

Some tasks grow the longer you work on them: research that never converges, a refactor that keeps finding more. Under a WIP limit an expanding task also holds a slot hostage, so set a time or effort box and force a decision when it is reached.

Constrain WIP in the part of the system where queueing is most expensive.

Not all queues cost the same: a queue of committed, half-built work ties up money and decays, while a queue of unstarted ideas costs little. Hold excess demand where it is cheapest and keep the expensive queue short.

Small, repeated reductions in WIP add up to large reductions in cycle time.

Ratchet the WIP limit down a little at a time, fix whatever problem the tighter limit exposes, then ratchet again. Each step is cheap and the effects on cycle time compound, much like reducing inventory to expose the rocks in lean manufacturing.

Make WIP continuously visible to everyone.

Product development inventory is invisible information, so represent each item as a physical or digital card on a board. Once people can see the pile in front of a stage, they self-organize to clear it.