Lesson 33: Kanban Framework

Lesson 32 gave you Scrum in full — a framework built around fixed-length Sprints, in which work is planned in batches and inspected at scheduled intervals. Scrum's cadence is one of its greatest strengths for teams whose work naturally comes in plannable chunks. But it is not the only serious answer to Lesson 31's underlying question — how do you structure execution so that feedback stays continuous rather than accumulating into late, expensive surprises? For teams whose work arrives unpredictably — support-driven engineering teams, infrastructure teams, teams handling a constant stream of inbound requests rather than a plannable backlog — forcing that work into two-week Sprint boxes can create friction rather than remove it.

This lesson introduces Kanban, the other dominant Agile implementation, built not around fixed iterations but around continuous flow. Where Scrum asks "what can we commit to for the next two weeks?", Kanban asks "how much work should be in progress at any given moment, and how do we keep it moving?" Understanding both frameworks — and, more importantly, understanding the underlying conditions that make one a better fit than the other — is what lets you make a genuinely reasoned recommendation to a team, rather than defaulting to whichever framework you personally learned first. This lesson also completes the two-lesson pair the Agile Fit Checklist from Lesson 31 was built to evaluate: you now have both a fixed-cadence and a flow-based implementation to test it against.

Learning Objectives

1
State Kanban's six core practices and explain the problem each one is designed to solve.
2
Explain what a Work-in-Progress (WIP) limit is, and why constraining the amount of work in progress can increase, rather than decrease, overall throughput.
3
Distinguish cycle time from lead time, and explain what each metric reveals that the other does not.
4
Apply the Agile Fit Checklist (Lesson 31) to compare Scrum and Kanban, and identify the specific conditions under which each framework is the better fit.
5
Diagnose a flow bottleneck using a cumulative flow diagram and a WIP-limit violation, and propose an appropriate response.

This lesson assumes fluency with Lesson 31's Iteration Loop and Agile Fit Checklist, since Kanban is evaluated here as a second concrete implementation of the same underlying values, not a new philosophy. It also assumes familiarity with Lesson 32's Scrum framework, because much of this lesson's value comes from direct contrast — Kanban is easiest to understand not in isolation but against the fixed-Sprint structure you already know, since the two frameworks make opposite bets about whether batching work into a fixed time-box helps or hinders flow.

The Origin: Flow, Not Batches

Kanban's modern software adaptation traces back to lean manufacturing principles, most famously the Toyota Production System, later adapted for knowledge work by David J. Anderson in the mid-2000s. Where Scrum's unit of commitment is the Sprint (a fixed time-box), Kanban's unit of attention is the item of work moving through a value stream — and its central bet is that limiting how much work is in progress at once, rather than how much time is allotted, is the more reliable lever for improving delivery speed and predictability.

The Six Core Practices

Practice	What It Solves
1. Visualize the workflow	Makes invisible knowledge work visible, typically as a board with columns representing stages (e.g., Backlog → In Progress → Review → Done)
2. Limit Work in Progress (WIP)	Prevents a team from starting more than it can finish, which is the single most common cause of slow, unpredictable delivery
3. Manage flow	Shifts attention from "are people busy" to "is work actually moving through the system smoothly"
4. Make process policies explicit	Ensures everyone shares the same definition of what it means for an item to move from one column to the next
5. Implement feedback loops	Establishes regular checkpoints (analogous to, but less rigidly scheduled than, Scrum's events) for reviewing flow and outcomes
6. Improve collaboratively, evolve experimentally	Treats the process itself as something to be iterated on using evidence, mirroring the Iteration Loop from Lesson 31 applied to the process rather than the product

Why Limiting WIP Increases Throughput

This is the single most counterintuitive idea in this lesson, and worth deriving carefully rather than simply asserting. Consider a team with five engineers and no WIP limit. Under pressure from many stakeholders, the team starts eight things simultaneously — every engineer context-switches between roughly 1.5 items on average. Context-switching carries a real, well-documented cost: every switch requires re-loading mental context, and that overhead is pure waste, contributing to none of the eight items' completion.

Now compare a team that limits WIP to, say, three items at a time. A fourth request must wait in a queue until one of the three in progress is finished. This feels, superficially, like it should be slower — after all, work is being deliberately delayed. But because the three in-progress items receive full, uninterrupted attention, they finish faster individually, and the team's overall completion rate (throughput) tends to rise, not fall, because the hidden cost of constant context-switching has been removed. This is Kanban's central, often initially resisted, claim: starting less work finishes more work.

Flow Metrics: Cycle Time and Lead Time

Two related but distinct metrics are essential to Kanban's "manage flow" practice, and new PMs frequently conflate them:

Lead time: the total time from when a request is made (entering the backlog) to when it's delivered. This is the metric a customer or stakeholder experiences directly — "how long did it take from when I asked to when I got it?"
Cycle time: the time from when work actually begins on an item to when it's delivered. This is the metric that measures the team's execution efficiency specifically, stripped of however long the item sat waiting in the backlog before anyone started it.

A team can have a short cycle time (fast once started) but a long lead time (items sit in the backlog for weeks before anyone picks them up) — this is an extremely common pattern, and one that a team focused only on cycle time will completely miss, because it's invisible to anyone only watching work once it's "in progress." Diagnosing which of the two is the actual problem determines whether the fix is "work faster once started" (rarely the real issue) or "start things sooner" (frequently the real issue, and much more within a PM's direct influence, since it's often driven by prioritization decisions rather than engineering execution speed).

The Cumulative Flow Diagram

A cumulative flow diagram (CFD) plots the number of items in each workflow stage over time, as stacked bands. A healthy CFD shows roughly parallel, steadily widening bands. A widening band for one specific stage — say, "Code Review" growing wider and wider while "In Progress" and "Done" stay flat — is a visual signature of a bottleneck: work is piling up at that stage faster than it's being cleared, exactly the kind of structural problem a WIP limit at that stage is designed to surface and force the team to confront directly, rather than allowing it to silently accumulate.

Common Mistakes to Avoid

Treating Kanban as "Scrum without the meetings.

Kanban is not merely an unstructured, ceremony-free version of Scrum — it has its own explicit practices (the six above), its own discipline (WIP limits, explicit policies), and its own feedback mechanisms. A team that drops Scrum's events without adopting Kanban's actual practices in their place has adopted neither framework's discipline, only the appearance of informality.

Setting WIP limits too high to avoid the discomfort of a full queue

A WIP limit only works if it's occasionally binding — if it never actually blocks anyone from starting new work, it isn't constraining behavior, it's decorative. New teams frequently set WIP limits generously enough that they're never hit, which defeats the entire mechanism described above.

Measuring "team busyness" instead of "flow.

A team where every engineer is constantly occupied can still have terrible flow, if what they're occupied with is a large number of half-finished items rather than a small number of completed ones. Kanban's "manage flow" practice exists specifically to redirect attention away from individual utilization and toward whether work is actually completing and moving downstream.

Confusing cycle time improvements with lead time improvements

As covered above, optimizing execution speed once work has started does nothing for items still waiting, unstarted, in a long backlog queue. A PM who reports "we improved cycle time by 20%" as evidence the team is now faster to deliver, without checking lead time, may be reporting a genuine but incomplete improvement — or masking a worsening backlog problem entirely.

Skipping explicit process policies

Without an explicit, shared definition of what it means for an item to be ready to move from one column to the next (e.g., what "Ready for Review" actually requires), teams experience constant, low-grade disputes about whether something is really done with a stage — the Kanban equivalent of the Definition of Done ambiguity covered in Lesson 32.

Mental Model

The Flow Valve

This lesson's core takeaway tool visualizes the WIP-limit mechanism as a valve controlling pressure through a pipe:

Use the Flow Valve as a diagnostic whenever a team reports feeling "busy but nothing's shipping." Ask: is the valve (WIP limit) actually constraining anything, or has it been set so loosely that everything passes through unimpeded, recreating the context-switching problem the valve exists to prevent? A team with no binding WIP limit is, functionally, a team with no valve at all — pressure (requests) flows straight through into an overloaded pipe (in-progress work), regardless of what the board visually implies.

Quick Reflection Checkpoint

Key Takeaway: How will you apply "The Flow Valve" when evaluating trade-offs in your product decisions?

Kanban Framework