Kanban Systems
Kanban (Japanese for 'signal card') is a pull-based workflow system invented at Toyota in the 1940s. Instead of pushing work into the next station whenever it's ready (which creates massive inventory), each station only requests work from upstream when it has capacity. Modern Kanban is built on three rules: (1) Visualize the work — make every task visible on a board with clear states (To Do, Doing, Done). (2) Limit Work in Progress (WIP) — cap how many items can be in each column. (3) Manage flow — measure cycle time and remove blockers, don't celebrate started work. The result: lower lead times, fewer defects from context-switching, and brutal honesty about what's stuck and where.
The Trap
Putting tickets on a Trello/Jira board and calling it 'Kanban.' That's just visualization without the discipline. Real Kanban requires WIP limits — typically 1-2 items per person — and they have to be enforced. If your board says 'In Progress: 47' for a team of 6, you don't have a Kanban system; you have a wishlist with a fancy UI. The other failure mode: WIP limits without flow analytics. Kanban without measuring cycle time and throughput is just a checklist; the data is the whole point.
What to Do
Set up a board with 4-5 columns reflecting your actual workflow (Backlog → Ready → In Progress → Review → Done). Set WIP limits per column based on team size — for a team of 6, Cap In Progress at 6 (one per person) or even lower (4) to force collaboration on blockers. Run a 2-week experiment: do not exceed WIP limits even if it feels uncomfortable. Measure cycle time (start → done) for each ticket weekly. The first 2 weeks will reveal the bottleneck (the column where work piles up). Then attack THAT column before doing anything else.
Formula
In Practice
Spotify's engineering teams operate on Kanban with strict WIP limits — typically 2 items per developer maximum. Their internal data showed that teams who exceeded WIP limits had 60% longer cycle times and 3x more defects (because of context-switching between tasks). When teams complained 'we have too much work', Spotify managers responded by tightening WIP limits, not loosening them. The result: Spotify ships hundreds of releases daily across thousands of engineers because work flows through, instead of clogging up.
Pro Tips
- 01
Little's Law is the math behind Kanban: Cycle Time = WIP / Throughput. If you have 30 tickets in progress and ship 5/week, your average cycle time is 6 weeks — period. The only way to ship faster is to either lower WIP or raise throughput. Hiring more people raises throughput AND raises WIP, often canceling out.
- 02
When you set WIP limits, expect screaming. The team will say 'but we have all this stuff to do!' That's the point. Kanban exposes that you've been STARTING work you can't finish. Holding the line for 2 weeks shows the team that finished work ships value; started work doesn't.
- 03
Color-code blockers in red on your board. The number of red tickets at any time is your single best predictor of next week's velocity. A board with 6 red tickets and 12 in progress will deliver almost nothing.
Myth vs Reality
Myth
“Kanban is the same as Scrum without the sprints”
Reality
Scrum batches work into 2-week sprints with fixed scope; Kanban is continuous flow with no batches. They have different cadences, different metrics, different risks. Kanban suits teams with constantly changing priorities (support, ops); Scrum suits teams that can plan a fixed deliverable (product features). Picking the wrong one creates chronic friction.
Myth
“More columns on the board = better visibility”
Reality
Each new column adds a handoff and a place for work to wait. 5-7 columns is the sweet spot. Boards with 12+ columns ('Coding,' 'Code Review,' 'QA Queue,' 'QA Active,' 'Staging,' 'PM Review,' 'Production Wait') are usually documenting bureaucracy, not managing it. Simplify the columns and you simplify the process.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Knowledge Check
Your team has 8 developers, 24 tickets currently in progress, and ships an average of 6 tickets per week. What is your average cycle time per ticket?
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets — not absolutes.
WIP per Knowledge Worker
Software engineering, design, product management teamsOptimal
1-2 items
Manageable
3-4 items
Context-Switching Tax
5-7 items
Throughput Collapse
8+ items
Source: DORA State of DevOps Report / David J. Anderson Kanban research
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
Toyota (Origin of Kanban)
1940s-Present
Taiichi Ohno designed Kanban after observing American supermarkets in the 1950s — shelves were restocked only when customers took products. He applied the same pull principle to Toyota's assembly lines: each station only built parts when the next station signaled need with a kanban card. This reduced inventory by 75%, eliminated overproduction (Toyota's #1 named waste), and enabled the just-in-time system that became the foundation of the Toyota Production System.
Inventory Reduction
75%
Overproduction Eliminated
~100%
Lead Time Reduction
60%+
Industry Influence
Adopted by every modern manufacturer
Kanban's power is in saying NO — no work starts unless the downstream signal pulls it. Push systems hide problems with inventory; pull systems reveal them immediately.
Hypothetical: 30-Person SaaS Engineering Org
Recent
A growth-stage SaaS company had 30 engineers organized into 5 squads, all using Jira boards with no WIP limits. Average cycle time per story: 18 days. Engineers reported feeling 'always busy, never done.' VP Eng instituted hard WIP limits: max 2 stories per developer, max 3 in code review per squad. First 3 weeks: chaos and complaints. Stakeholders had to actually pick what mattered most because the team could no longer 'take everything.' By week 6, average cycle time was 7 days. Throughput rose 40% (more shipped, less started). Two squads went on to adopt continuous deployment.
Cycle Time
18 days → 7 days
Throughput
+40%
WIP per Engineer
5+ → 2 (capped)
Engineer Burnout (Survey)
-30%
Capping WIP is the highest-leverage operational intervention available to a software org. Every team feels they have too much work; almost none have enforced WIP limits.
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn Kanban Systems into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn Kanban Systems into a live operating decision.
Use Kanban Systems as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.