A Kanban Board Without a WIP Limit Is a Status Report

Kanban has one control that does the work: the work-in-progress limit. Everything else, including the board, is a view of the system.

Teams adopt the board first because the board is easy and visible. Columns, colors, swimlanes for each customer. Six weeks later the board is accurate and the team is still slow, because a board with no limit measures the queue instead of constraining it.

Why the limit is the whole mechanism

The board visualizes work. The limit changes behavior.

When a column is full, the next item cannot enter, which means the person who would have started it has to help finish something already in the column. That is the mechanism. It converts a group of individuals working in parallel into a system that completes work.

The math is not complicated. Little's law says the average number of items in a system equals the arrival rate times the average time each item spends in it. Rearranged, the time an item spends in the system is the work in progress divided by the throughput.

If your throughput is fixed by the number of people and their skills, the only variable left is how much you start. Start more, and everything takes longer. That is not a management opinion. It is arithmetic, and it holds whether or not anyone has read the theorem.

Starting less is the only lever that shortens the time to finish.

The practical consequence is that a WIP limit is not a suggestion about focus. It is a constraint on the arrival of work, and it will feel wrong for the first month because it makes the queue outside the team visible.

The metric that lies

Average cycle time is the number most teams report, and it is the one that hides the problem.

An average is a single number describing a distribution, and work arrival distributions have long tails. A team with an average of four days can be delivering most items in two days and a meaningful minority in three weeks. The average says four. The customer experiences three weeks.

Watch the tail instead: the 85th percentile, or the oldest item in progress, or a scatterplot of cycle time by completion date. The tail is where the commitments break, and it is where an improvement shows up first.

Two other views earn their place. A cumulative flow diagram shows work in progress accumulating as a widening band, which is the earliest visible signal that a stage is constraining the system. And a count of items that have been in progress longer than the team's own limit tells you where to look this week without a meeting.

Where Kanban breaks in federal work

The standard board has columns for analysis, development, test and done. That board describes the part of the workflow the team controls, which in a federal program is usually the smaller part.

The real workflow includes a security review, an environment request, an approval from a change board, and a customer acceptance step. None of those appear on the board, so none of them are measured, so the team optimizes the only thing it can see and the program stays late.

The fix is to put the waiting columns on the board and treat them as work in progress. An item sitting in an approval queue is in the system. It consumes time, it counts against the limit, and it is usually the constraint.

Two rules make that honest. Give each waiting column a named owner outside the team, and put a limit on it too. A security queue with forty items and one reviewer is a constraint you can see, and seeing it is the precondition for staffing it.

Starting on Monday

Four steps, in order, none of them requiring a tool purchase.

1. Write the workflow as it is, not as it should be. Every state an item passes through, including the waiting states owned by other people.
2. Count what is in each state today. That snapshot is your baseline, and it will be uncomfortable.
3. Set a limit on the states you control. A common starting point is one item per person in the active states. Lower it when the team is comfortable, not before.
4. Review the oldest item weekly. Not the average. The oldest. Ask why it is old and what would finish it.

Kanban is often described as a way to visualize work. That is the least interesting part. It is a way to decide, every day, what not to start, and to make the cost of starting too much visible to the people who are adding work.

The board is how you show them. The limit is how you change the outcome.