Kanban

Kanban is a method for managing work that emphasizes visualizing the workflow, limiting work in progress, and managing flow, rather than organizing delivery into fixed time-boxed batches. It originated in manufacturing at Toyota and was adapted for knowledge work, and its central mechanism is that new work is pulled into the system only when capacity becomes available rather than pushed in on a schedule.

The visual board is the most recognizable element but not the most important. Columns representing the actual stages work passes through, with each item visible as it moves, makes the state of the system observable to everyone. What matters is that the columns reflect reality, including the waiting states where work sits idle awaiting review, approval, or another team, since those queues are usually where most of the elapsed time is spent and they are invisible on simplified boards.

Limiting work in progress is the mechanism that produces the benefit, and it is the element organizations most resist. Constraining how many items may be in each stage feels like reducing productivity, but the effect is the opposite: starting fewer things simultaneously means each finishes sooner, context switching falls, and the queue of half-completed work stops growing. Teams that begin everything requested and finish little are the situation the limit is designed to correct.

The limit also functions as a diagnostic. When work cannot move forward because the next stage is at capacity, the constraint becomes visible immediately and the team's attention is directed at unblocking it rather than at starting something new. This is what converts a board from a tracking device into a management tool, and it is why boards without limits typically become a display of everything in progress rather than a means of improving flow.

The metrics differ from those used in iteration-based approaches and are more directly meaningful. Cycle time measures how long an item takes from start to completion, throughput measures how many items complete per period, and the distribution of cycle times supports probabilistic forecasting of when future work will finish. These are observed rather than estimated, which avoids the estimation effort that consumes considerable time in other approaches.

The method's evolutionary premise distinguishes it from frameworks that prescribe a structure. Kanban begins with the process as it currently exists, makes it visible, and improves it incrementally, rather than requiring new roles and events. This makes adoption less disruptive and more politically feasible in organizations that resist reorganization, though it also means that a team applying it superficially can carry on exactly as before with a board attached.

It suits some contexts better than iteration-based approaches. Work arriving unpredictably, support and maintenance, operational teams, and any situation where commitments to a fixed batch are repeatedly disrupted all fit flow management better than sprint planning. Many teams combine elements of both, using a cadence for planning and review while managing the work itself by flow, which is a pragmatic arrangement rather than a compromise.

Because the improvement comes from confronting queues and constraints that frequently sit outside the delivery team, the method often surfaces organizational bottlenecks rather than team ones. In practice it is applied within product development and is equally applicable to design and research pipelines, and organizations running mixed delivery and operational work frequently adopt it across an IT department where unpredictable arrival makes fixed-batch commitment impractical.