Kanban Method

The Kanban Method is a change management method applied on top of existing workflows. Unlike Scrum, it prescribes no fixed iterations — work flows continuously, pulled by capacity rather than pushed by a schedule (bib).

Six general practices

Visualize — make invisible knowledge work visible on a board. Transparency is the foundation of all other practices.
Limit Work in Progress (WIP) — focus on flow, not utilization. Full utilization produces congestion, not throughput. “Stop starting, start finishing.”
Manage flow — complete work as smoothly and predictably as possible. Core metrics: lead time, delivery rate, WIP.
Make policies explicit — pull criteria, WIP limits, service classes, meeting cadences. Policies enable self-organization, not rigid work instructions.
Implement feedback loops — board, metrics, and cadences (regular meetings/reviews). Feedback loops strengthen learning and enable evolution.
Improve collaboratively, evolve experimentally — safe-to-fail experiments based on models and data. If results are negative, roll back.

Pull system and WIP limits

In traditional project management, work is pushed into the system based on deterministic plans. Kanban reverses this: a pull signal is generated when the WIP limit is not fully utilized. Work enters only when there is capacity. This creates flow where finishing is valued over starting.

WIP limits function as enabling constraints: they force collaboration, surface bottlenecks, and prevent the context-switching that destroys effectiveness in knowledge work.

Continuous flow vs fixed iterations

This is Kanban’s fundamental difference from Scrum and OKR. There are no sprints, no quarters — work items flow continuously through the system. The cycle time is the life of a single work item, not a fixed timebox.

The user’s xettel calls Kanban the most radical step in shortening the feedback cycle: cycle time = single work item. Where OKR samples quarterly and Scrum samples per sprint, Kanban provides continuous feedback through board visualization and flow metrics.

Feedback through cadences

Kanban systems evolve feedback loops over time. Cadences are regular meetings at varying frequencies:

Daily — team-level coordination (like Scrum’s daily standup)
Weekly/biweekly — replenishment, delivery planning
Monthly/quarterly — service delivery review, strategy review

The guide emphasizes building cadences gradually and fitting them to context rather than prescribing a fixed set.

Connection to control theory

Kanban maps cleanly to feedback control:

Visualize = observability — you can see the system state
WIP limits = the actuator constraint — capacity-based pull prevents overload
Flow metrics = the sensor — lead time, delivery rate, cumulative flow diagrams
Cadences = the comparator — regular inspection of actual vs expected flow
Evolutionary improvement = the control loop itself — measure, compare, adjust

Unlike empirical process control in Scrum (where the loop fires per sprint), Kanban’s feedback is continuous — the board itself is a real-time sensor.