Skip to main content
business computer-science family-and-consumer-science medicine-and-health transportation

​
Kanban

​
Description

Kanban (Japanese: 看板, “signboard” or “billboard”) is the lean-manufacturing primitive that makes work-in-progress visible, caps how much can be in flight at each stage, and uses downstream capacity as the signal that authorizes upstream production. Taiichi Ohno developed it at Toyota as the operational backbone of just-in-time production: instead of upstream stations pushing parts forward on a schedule, downstream stations pull parts as their own work-slots clear. The kanban card — initially a literal slip of paper attached to a parts bin — is the authorization token; no card returned means no production authorized. Three structural elements together produce the concept. Visibility: the board, the column, the card, the physical lane — the queue at each stage is observable without inspection or status reports. WIP limits: each stage has an explicit cap; when the cap is reached, upstream must stop. Pull signal: downstream’s clearing of capacity is the active signal authorizing upstream’s next move; no autonomous upstream production. The diagnostic that distinguishes kanban from a generic queue: can upstream send whenever it wants, or must it wait for a downstream signal? A bare queue is push-based; absorption is the queue’s job. Kanban is pull-based; the queue refuses to absorb beyond its cap, and upstream waits until downstream signals. That refusal is what produces the system-level visibility of bottlenecks, the natural smoothing of throughput, and the disciplined response to demand changes.

​
Triggers

User-initiated: User describes a workflow problem in terms of “too much in flight,” “things pile up,” “we keep starting things we don’t finish,” “upstream just dumps on us.” Vocabulary cues: “WIP limit,” “kanban,” “pull system,” “visualize the work,” “see the bottleneck.” Agent-initiated: Engine notices the user is debating throughput, queue depth, or work-prioritization without a visibility/cap/pull architecture; the structural lever is making the queue visible and capping it rather than negotiating priorities. Candidate inference: “the issue is that upstream and downstream aren’t coordinated by an explicit signal — what would a kanban implementation look like here?” Situation-shape signals: Multi-stage workflows with hidden queues; bottlenecks that no one names because no one sees the queue depth; pressure to “start more things” because finished things aren’t visible; teams that say “we don’t know what everyone is working on right now.”

​
Exclusions

  • Single-stage operations — kanban presupposes multiple stages with hand-offs; a one-stage operation has nothing to signal between.
  • Highly variable processing time at each stage — kanban works best when stage-processing-time is roughly bounded; extreme variance breaks the cap-and-pull discipline.
  • Demand far exceeds capacity over the long run — kanban makes the over-capacity demand visible but doesn’t solve it; the concept is for coordinating capacity, not creating it.

​
Structure

Internal structure of kanban: a table of its component slots and the concepts that fill them.

​
Relationships

Relationship neighborhood of kanban: a graph of the concepts it connects to and the concepts it is a part of.
  • backpressure — kanban is the visible-and-physical instantiation of backpressure; the WIP limit and pull signal implement backpressure operationally.
  • flow — kanban presupposes flow; it regulates flow’s pace via the cap-and-pull discipline.
  • bottleneck-buffer — the WIP-limited buffers at each stage; the bottleneck is the always-full stage.
  • doctrine — “no work starts without a kanban signal” is a doctrine in the sense of named-rule + triggering-condition + protected-against-failure.

​
Examples

Toyota production lines · business

the canonical instance; kanban cards travel between stations to authorize part-production in synchrony with downstream consumption.

Software development boards · computer-science

Trello, Jira boards, GitHub Projects; the To-Do / In-Progress / Review / Done columns with explicit WIP-limits per column. The team’s “we’re at our WIP limit on review” is the kanban refusal.
runway slots and approach corridors are kanban capacity; arrivals are throttled when downstream (runway, taxiway) is at WIP-limit.
David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (2010) — the software-development adaptation that brought kanban into engineering practice.
Donald Reinertsen, The Principles of Product Development Flow (2009) — the underlying queueing-theory case for WIP-limits and pull-based flow.
Goldratt’s The Goal supplies the theory that explains why kanban’s central rule — limiting work-in-progress — works. The Theory of Constraints holds that any system’s throughput is set by a single binding constraint (a bottleneck), and that improvement anywhere other than the constraint is illusory: “an hour saved at a non-bottleneck is a mirage,” because it does not raise the system’s total output. The decisive corollary is that the way to find the constraint is to control inventory. In a system with unlimited work-in-progress, work piles up everywhere and the bottleneck is camouflaged. Limit WIP — starve the non-bottlenecks of busy-work — and work immediately accumulates at exactly one place: just upstream of the constraint, which now stands out plainly.This is precisely the mechanism a kanban board exploits. The column-level WIP limits are TOC’s diagnostic instrument made visible on a wall: when one column keeps filling to its cap while the next stays empty, the board has located the bottleneck for you. Goldratt’s Drum-Buffer-Rope scheme is the same idea formalized — the constraint (Drum) sets the pace, a small buffer protects it from starving, and the “rope” (the kanban pull signal) prevents new work from entering faster than the constraint can absorb it. Goldratt’s five focusing steps (identify, exploit, subordinate, elevate, repeat) are the discipline that follows once the WIP limit has surfaced the constraint.Inference: A kanban WIP limit is not primarily a productivity rule; it is a measurement device. Its job is to make the system’s single binding constraint observable by forcing work to queue at it rather than spreading out as hidden inventory. The portable diagnostic: if you cannot see where your bottleneck is, you almost certainly have too much WIP masking it — tighten the limits until the queue forms, and the constraint reveals itself.
admissions throttled by available beds; the empty bed is the kanban card returning to admissions, authorizing the next intake. ED boarding occurs when the kanban signal is broken (no beds, but admissions don’t slow down).
the ticket rail’s physical length is an implicit WIP-limit on simultaneous orders; expediters pull tickets as cooks clear stations.
shelf gaps as the signal to the backroom or distribution center; the gap itself is the kanban authorization.
The kanban board adapts the manufacturing kanban concept to knowledge work: columns represent stages of work (typically along the lines of “to do,” “in progress,” “review,” “done”), and cards represent units of work that move left-to-right through the columns. The visual board makes the work-in-progress at each stage explicit; many kanban-style workflows add explicit work-in-progress (WIP) limits on intermediate columns to prevent any one stage from accumulating a backlog.The structural fidelity to manufacturing kanban is strong despite the very different physical setting. The board makes pull-based scheduling visible (a downstream column with capacity pulls the next item from an upstream column); the WIP limits enforce the pull discipline; and bottlenecks are diagnosable from the board itself by looking at which columns are full and which are starved.
canonical Toyota Production System primitive — Ohno developed kanban as the signaling mechanism that converted Toyota lines from push-based scheduling to pull-based demand. Cross-domain instances: software development (kanban boards: To-Do / In-Progress / Done columns with WIP limits per column); hospital bed management (admission throttled by available beds; the empty bed is the kanban card); retail just-in-time inventory (shelf gap is the pull signal to backroom); air-traffic control (runway slot is the pull signal to approach); restaurant kitchens (ticket-rail visualization with implicit WIP-limit by physical rail length)
Kanban as a manufacturing method originates in the Toyota Production System developed by Taiichi Ohno and colleagues at Toyota in the postwar period. The Japanese word “kanban” refers to the physical cards or signal devices used on the factory floor: an upstream station produces only when a downstream station signals demand for more parts, via the kanban card that travels backward along the production line.The structural move is to invert the default of push manufacturing — where upstream stations produce and pile up inventory whether or not downstream needs it — into pull manufacturing, where production is gated by downstream pull-signals. This eliminates the inventory buffers that would otherwise accumulate between mismatched stations and forces problems in the line to surface immediately rather than being hidden by intermediate stockpiles.Inference: When a pipeline of work shows growing intermediate inventory or queues, the structural diagnosis is that upstream is push-driven rather than pull-driven. Replacing the implicit push with an explicit pull signal — kanban-style — both throttles upstream and surfaces downstream bottlenecks immediately.