Every process has a speed limit. Not the speed you wish it had, not the speed your project plan assumes — the actual rate at which work can flow through the system. Most organizations blow past that limit every day, cramming more work into the pipeline and wondering why everything takes forever.
Kanban is the antidote. Originally developed at Toyota for manufacturing, it's a deceptively simple system built on one radical idea: limit the amount of work in progress, and let demand pull work through the system.
The Problem with Push
Most organizations run push systems. Work is pushed into the pipeline as soon as it arrives. New project? Start it. Customer request? Queue it. Idea from leadership? Add it to the list.
The result is predictable and universal: too much work in progress (WIP). And high WIP is the silent killer of process performance.
Here's why, and it's not intuitive: starting more work doesn't get more work done. It gets less done. As WIP increases:
- Lead times explode. Little's Law (Tip 014) tells us that lead time = WIP ÷ throughput. If throughput is fixed (and it usually is — you have finite people and machines), more WIP means proportionally longer lead times.
- Context switching increases. People juggle more tasks, spending time remembering where they left off instead of making progress.
- Quality drops. Rushed, fragmented attention produces more errors, which create rework, which adds more WIP.
- Priorities become impossible. When everything is "in progress," nothing is actually prioritized. Work competes for the same resources in an unmanaged free-for-all.
- Visibility disappears. With 47 active projects, nobody can tell which ones are on track, which are blocked, and which quietly died three weeks ago.
Push systems feel productive because everyone is busy. But busyness and productivity are not the same thing.
How Kanban Works
Kanban introduces three core practices that transform how work flows:
1. Visualize the workflow.
Create a board — physical or digital — with columns representing each stage of your process. Every piece of work gets a card. Cards move left to right as work progresses. At any moment, you can see the state of everything: what's waiting, what's active, what's blocked, what's done.
This sounds trivial. It's not. Most teams have no shared, real-time view of their work. They have spreadsheets that are outdated by lunch, status meetings that report last week's state, and individual to-do lists that nobody else can see. The board changes everything because it makes the invisible visible.
2. Limit work in progress.
This is the heart of kanban. Each column on the board has a WIP limit — a maximum number of cards allowed in that stage at any time. When a column is full, no new work enters until something exits.
If the "Review" column has a WIP limit of 3 and there are already 3 items being reviewed, the upstream stage cannot push more work into review. It must wait. Or better — help clear the bottleneck.
WIP limits feel counterintuitive, even uncomfortable. "We have capacity! We should be starting new work!" But the math is clear: limiting WIP reduces lead time, improves throughput predictability, and exposes bottlenecks. It trades the illusion of productivity for actual productivity.
3. Manage flow, not people.
Traditional management assigns tasks to people and tracks individual utilization. Kanban manages the flow of work through the system. The question shifts from "Is everyone busy?" to "Is work moving smoothly?"
When a card is blocked, the system makes it visible. When a stage is starved or overloaded, the WIP limits make it obvious. Problems surface naturally instead of hiding behind status reports.
Setting WIP Limits
The most common question: how do you choose the right WIP limits?
Start with what you have. Count how many items are currently in each stage. That's your baseline. It's probably too high, but it's where you are.
Reduce gradually. Drop WIP limits by 10-20% at a time. Each reduction will feel slightly uncomfortable — that's the system surfacing problems you need to solve. If it doesn't feel uncomfortable, you haven't reduced enough.
A useful starting formula: WIP limit = number of people working that stage × 2. This allows for some parallel work and handoff overlap without creating pile-ups. Adjust from there based on what you observe.
Watch what happens. When you lower WIP limits, work will back up somewhere. That somewhere is your constraint. Now you know exactly where to focus improvement efforts. This is a feature, not a bug.
The ideal end state is single-piece flow — a WIP limit of 1 per person. Most organizations aren't ready for that, but it's the direction to move.
Pull vs. Push in Practice
In a push system, upstream stages push work forward whenever they finish. In a pull system, downstream stages signal when they have capacity.
The difference is subtle but profound:
Push: "I finished this. Here you go." (Regardless of whether the next stage is ready.)
Pull: "I have capacity. Send me the next one." (Work only moves when there's room for it.)
Pull systems prevent overloading. They create natural pacing. And they make bottlenecks impossible to ignore — because when a bottleneck stage can't pull, everything upstream visibly stops. The pressure to fix the constraint becomes organizational, not just local.
Kanban Beyond Software
Kanban has become synonymous with software development, but its principles apply to any workflow:
- Healthcare: Patient flow through an ER. Limit the number of patients in triage simultaneously to prevent the waiting room from becoming a warehouse of forgotten cases.
- Legal: Case management. Limit active cases per attorney to ensure timely progress instead of 40 open files with none moving forward.
- Manufacturing: The original use case. Parts aren't produced until the downstream station signals need. No signal, no production, no excess inventory.
- Marketing: Campaign pipeline. Limit campaigns in "creative development" so the design team finishes work instead of starting 12 projects and delivering none.
Anywhere work flows through stages with limited capacity, kanban applies.
The Metrics That Matter
Once you implement kanban, track these:
Lead time: How long from request to delivery? This is what the customer feels. WIP limits should bring this down.
Throughput: How many items completed per time period? Paradoxically, limiting WIP often increases throughput because it reduces context switching and rework.
WIP age: How long has each in-progress item been in the system? Old items signal blockages. A card that's been "in progress" for three weeks isn't in progress — it's stuck.
Blocker frequency: How often do items get blocked, and why? Patterns in blockers reveal systemic issues worth solving.
Common Mistakes
Setting WIP limits too high. If your WIP limit matches your current WIP, you haven't changed anything. The limit should create mild, productive tension.
Ignoring the limits. "Just this once, we'll exceed the limit for this priority item." Once you start making exceptions, the system collapses. The limits only work if they're respected.
Focusing on local optimization. A stage that maximizes its own throughput while starving or flooding adjacent stages isn't helping. Optimize for system flow, not stage efficiency.
Skipping the visualization. The board isn't optional decoration. It's the management system. Without shared visibility, kanban degrades to "we put sticky notes on a wall once."
The hardest part of kanban isn't the mechanics. It's the mindset shift. We've been conditioned to equate starting with progress and busyness with productivity. Kanban asks you to believe something uncomfortable: the fastest way to get more done is to do less at once. The math backs it up. Every time.