Managing WIP and Flow

Your instinct, and your stakeholders' instinct, is that a fully loaded team is a fast team. Kanban makes the opposite claim, and it is the foundation of everything in this unit: a busy system is not a fast one. Flow, the steady movement of work to done, is what you actually want, and chasing utilization, keeping every person loaded to 100%, quietly destroys it.

Here is why. When everyone is maxed out, new work doesn't get done sooner, it queues. Items pile up waiting between stages, people juggle three things at once, and the time from "started" to "shipped" balloons. The lever that fixes this is work in progress (WIP), the count of items open at any moment. Deliberately holding WIP below full capacity leaves a little slack, and that slack is exactly what lets the team finish, respond, and pull the next thing smoothly. Optimizing for flow over utilization is the mindset shift the rest of this unit builds on.

The way you turn that principle into a control is a WIP limit: the maximum number of items allowed in a column, or on the board, at once. Set it from your team's real capacity, not an aspiration. A practical starting point is to look at how many items the team genuinely makes progress on at a time and cap slightly below that, then adjust as you learn. The limit's job isn't to be perfect on day one; it's to change behavior. When a column hits its cap, you cannot start something new, so the fastest path forward is to finish or help finish what's already there.

• Natalie: A limit of three in development? Some days I'll have nothing of my own to start.
• Milo: That's the point. If the column is full, the quickest way to open a slot is to help finish what's already in it.
• Natalie: So instead of pulling a fourth ticket, I go review or pair on one that's nearly done.
• Milo: Right. We're not asking you to do less, we're asking the team to finish more before it starts more.
• Natalie: And the limit makes that the obvious move instead of a judgment call.

Notice Milo never argues about who looks busy. He ties the limit straight to finishing, which is the only framing that survives the team's fear of looking idle.

Once WIP limits are in place, something useful happens: work stops piling up everywhere and starts piling up in one place. That place is your bottleneck, the stage with the least capacity relative to the demand flowing into it, and it sets the pace of the entire system. You spot it where the queue in front of a column keeps growing while stages downstream sit starved and waiting.

Resist the reflex to just tell that stage to work harder. Relieve it instead. You can shift capacity toward the constraint, reduce the load arriving by tightening the upstream WIP limit, or improve the work at that stage so each item moves through faster. Whatever you choose, watch for the predictable sequel: relieving one bottleneck usually reveals the next one. That is normal, and it means your system is improving, not failing.

The last piece is the gate. When the demand arriving at the team consistently exceeds its capability to deliver, queues grow without bound no matter how disciplined the limits are. Your job as Delivery Lead is to let new work enter only when there's genuine capacity to pull it. The hard moment is when a stakeholder wants something started now and every stage is already at its limit. Starting it doesn't make it finish sooner; it pushes everything else back. So make the trade visible and offer a real choice: replace something currently in flight, wait for a slot to open, or expedite this explicitly while naming what it delays.

The single idea holding this unit together: a team that starts less and finishes more delivers faster, because protecting flow beats maximizing how busy everyone looks. This is where it gets concrete. You'll first sharpen your judgment on when to favor flow over utilization, then turn data into an actual WIP-limit proposal and a bottleneck brief you could hand to leadership, and finally hold that line live with an impatient executive who equates "start now" with "done sooner." Try this before then: pick one column today and ask what would have to change if you capped it.