Make flow visible and use pull with intention
This domain tests board design and the discipline of pull: work moves because a policy says so, not because someone pushes harder or shouts louder.
Make the work visible
Cards carry work item type, class of service, the date they entered the state (age), a blocker flag and, where useful, the person working on it. Columns are states of work; blocked work is shown explicitly with its own age. Policies are posted next to the board, not stored elsewhere.
Pull with intention
Work enters a state only when two conditions hold: capacity exists (the WIP limit is not reached) and the item meets that state's pull criteria, selected according to its class of service. The selection is a policy decision - the oldest standard item, an expedite within its cap, a fixed-date item at risk - not a matter of escalation.
Commitment point and lead time
Lead time runs from the commitment point, where the service commits to the customer, to the delivery point. Cycle time starts when work begins. Put the commitment point visibly on the board so lead time is measured consistently. A visible line of commitment also shows how much work is still optional.
Worked example
Board: Options / Analysis (WIP 3) / Development (WIP 4) / Test (WIP 2) / Done. Development has two free slots, but Test is at its limit and its oldest card is six days old. Pulling more into development only lengthens the queue in front of test, so the intentional pull is refused and the team swarms on the ageing test item. Meanwhile an expedite incident uses the reserved slot and bypasses the standard queue - because policy allows it, not because someone panicked.
Traps that cost marks
- Breaking WIP limits "just this once" under pressure.
- Using the board as a status tracker for managers rather than a flow model.
- Cards without class of service or age, so priority and staleness are invisible.
- Blockers that stay implicit, hidden in conversation.
- No marked commitment point, so lead time means something different to everyone.