kanban

Set initial per-column WIP limits at roughly 1.5 to 2 times the number of people working in that column, and cap per-person WIP at one or two items. Watch the board for a week, then lower limits where work accumulates to expose bottlenecks.

Scrum uses time-boxed sprints, mandated roles, and sprint commitments, while Kanban uses continuous flow, explicit WIP limits, and no required roles. Kanban fits unpredictable or mixed work like support and ops; Scrum fits batched product work needing cadence.

Look for the stage where WIP accumulates upstream and work queues in a ready position while that stage stays fully utilized. Then apply the Five Focusing Steps: identify, exploit, subordinate, elevate, and repeat.

Track cycle time, lead time, and throughput, visualized on a Cumulative Flow Diagram. Little's Law connects them: cycle time equals WIP divided by throughput, so reducing WIP reduces cycle time at constant throughput.

Common causes are missing or too-high WIP limits, no flow metrics, standups becoming status reports, and stopping at visualization without managing flow. A board without WIP limits and explicit policies is a visualization tool, not Kanban.

Kanban fails when work items cannot be sliced small, when managers override the team's WIP authority, when the bottleneck sits outside the team's control, or when the team will not write down explicit policies.