Kanban is much older than Scrum — and it did not begin in a software company. It began with respect for people on a factory floor.
Sakichi Toyoda invents an automated stop mechanism for looms: a loom that halts itself the moment a thread breaks, preventing defects from continuing through production. This principle becomes known as Jidoka (automation with a human touch) — machines detect problems and stop until they are resolved.
Taiichi Ohno integrates Jidoka into what becomes the Toyota Production System (TPS). Workers are empowered — expected — to stop the line when defects are detected. The result: higher quality, efficiency, and what the world now calls lean manufacturing. Kanban, the card-based pull system at the heart of TPS, is born here.
Seventeen people gather at a ski hill in Snowbird, Utah, and write the Manifesto for Agile Software Development — a few words that reinvent the software industry and much more beyond it.
David J. Anderson applies theory-of-constraints thinking and a Kanban pull system to a project in Microsoft's IT department, becoming pivotal in bringing Kanban into modern knowledge work.
No, Microsoft did not invent Kanban in 2004. Kanban is the source of Agile methodology, founded on a life principle of community value — value seen from the point of view of the worker, the organization, and the community. And Agile is not owned by any alliance or institute; it belongs to the people doing the work.
TPS is deeply rooted in respect for people and continuous improvement (Kaizen). Its core community values:
Respect for People — empowering employees to improve processes and contribute ideas.
Teamwork & Collaboration — stakeholders working together in a harmonized workflow.
Continuous Improvement (Kaizen) — everyone identifies inefficiencies and suggests improvements.
Eliminating Waste — reducing overproduction, waiting time, and unnecessary movement.
Customer First Mindset — quality, reliability, and responsiveness drive all operations.
Long-Term Thinking — stability over short-term profits, a sustainable workforce, sustainable practices.
In this model, the workers own the Kanban board. Managers support, train, and empower — and the people doing the work self-organize, pulling from a short list of cards and moving each task to a known "complete" state in a visible workflow.
1. Visualize the workflow — the entire process on a board, each task a card moving through defined stages. Bottlenecks become visible.
2. Limit work in progress (WIP) — maximum limits per stage prevent overload; finish work before starting more.
3. Pull, don't push — new work starts only when capacity is free. Demand-driven, no overproduction.
4. Manage flow — smooth, steady, predictable movement rather than bursts of activity.
5. Make policies explicit — clear rules for how cards move, and what "done" means.
6. Feedback loops — regular reviews, stand-ups, and retrospectives to adjust priorities.
7. Continuously improve (Kaizen) — changes based on real-time data and team insight.
| Kanban | Scrum | |
|---|---|---|
| Structure | Visual boards and cards; no fixed roles or ceremonies | Defined roles (Scrum Master, Product Owner, Team) and ceremonies (sprints, stand-ups, reviews, retrospectives) |
| Rhythm | Continuous flow — work is pulled as capacity allows | Time-boxed sprints, typically 2–4 weeks, with committed scope |
| Planning | Minimal, just-in-time | Detailed upfront sprint planning |
| Metrics | Lead time and cycle time | Velocity (work completed per sprint) |
| Best for | Teams needing flexibility and flow efficiency | Teams preferring clear structure and deadlines |
How do you say "Kanban"? The Japanese pronunciation is softer — "kahn-bahn," closer to con than can. I learned the word in a group of phoneme-deficient, dyslexic leaders who read it rather than heard it, so "Can-Ban" lives on. The correct answer to "should I say Can-Ban or Kahn-Bahn?" is: yes.