Kanban and Framework Fit

A hospital discharge desk. Patients ready to leave arrive unpredictably — three before lunch, none for two hours, five at once at four o'clock. Now try to run that desk in two-week Sprints. Plan the fortnight's discharges in advance? Commit to a Sprint Goal? The idea is absurd — and that absurdity is the point. Scrum's rhythm is powerful, but some work refuses to arrive on a rhythm. For that work, there's a second way to create order. It doesn't box time at all. It limits the work instead.

By the end of this video, you'll be able to describe Kanban in one sentence and name its six practices, compare Scrum and Kanban without declaring a winner, and pick the right starting point — including the blend — for any scenario you're handed.

Kanban is a flow method: visualize the work, limit the work in progress, and manage the flow. That's the spine. No sprints, no prescribed roles, no new job titles. And that reveals Kanban's most distinctive property: it's evolutionary. You don't reorganize to adopt it — you start exactly where you are, with the process and titles you already have, make the work visible, and improve from there. Scrum installs a structure; Kanban overlays your existing one.

The name is Japanese — roughly, "signboard" — and the lineage runs straight back to Toyota's factory floors, the Lean tradition: cards signaling demand, so that work is pulled through the system when capacity frees up rather than pushed onto people regardless of load. Keep that word, pull. It becomes the hero of Module 4.

Fully grown, Kanban is six practices. First, visualize the work — the board: columns for the real stages, cards for the items. Second, limit work in progress — caps on how much can occupy a stage at once. Third, manage flow — watch how work moves, find where it sticks. Fourth, make policies explicit — write down what the columns mean and when a card may move. Fifth, build feedback loops — regular moments to inspect the system. Sixth, improve collaboratively — evolve the process together, by evidence.

If the first three sounded like headlines and the middle ones sounded abstract — good instinct. The board, the limits, the flow, the bottlenecks: all of it gets a full, hands-on treatment in Module 4, including a simulator you'll run yourself. Today is the map; Module 4 is the territory.

Now the comparison — once, cleanly, no winner. Scrum creates order through time: fixed cycles, a cadence of events, commitment expressed as a Sprint Goal. Kanban creates order through limits: continuous flow, no required cadence, commitment expressed as WIP caps. Scrum prescribes three accountabilities; Kanban prescribes none — you keep your titles. Both are empirical to the bone: visible work, frequent inspection, adaptation. They are two different answers to the same question — how do we stop chaos without installing bureaucracy? — one boxes the calendar, the other caps the load.

So which, when? Here's the heuristic that covers most cases. Work that arrives in plannable batches and benefits from a drumbeat — building a product, running a campaign, organizing that festival from last lesson — shines under Scrum: the rhythm concentrates effort and the Review concentrates feedback. Work that arrives continuously and unpredictably — support desks, operations, our discharge desk — shines under Kanban: you can't schedule the unpredictable, but you can absolutely limit and flow it.

And then there's the blend with the honest name: Scrumban — Scrum's cadence and roles carrying Kanban's board discipline and WIP limits inside it. Far from being a compromise for the indecisive, it's how a great many real teams actually operate. You already have the principle that blesses this, from Module 1: fit over fashion. The frameworks are fittings; the work decides.

You might think Kanban is Scrum's little sibling — the easy version for teams not ready for "real" agile. That's understandable: fewer rules reads as less serious. Actually, fewer prescriptions cuts both ways. Scrum's structure forces certain healthy behaviors — the retrospective happens because the calendar says so. Kanban forces almost nothing, which means its discipline must come from the team: limits actually honored, policies actually written, flow actually managed. Lighter framework, heavier self-discipline. Neither is the junior option; they're different contracts with yourself.

Three things to keep. One: Kanban — visualize, limit WIP, manage flow; evolutionary, no new roles, pull not push; six practices, deep-dived in Module 4. Two: Scrum orders by time, Kanban orders by limits; both are empirical; neither is the winner. Three: plannable batches lean Scrum, continuous-unpredictable leans Kanban, and Scrumban is a legitimate craft — fit over fashion.

Frameworks are the visible part of a team — the boards, the events, the vocabulary. But every framework you've met runs on something invisible, and when it's missing, all of them fail identically. Next lesson: the invisible part — and the research that proved it's the part that matters most.