Topic 6 — Kanban and other approaches

Goal: Understand Kanban, waterfall, and how to choose an approach.

Lesson 6.1 — The squad that never finishes anything

Three weeks into running the driver-app squad at Cartwheel, Renata notices something that nags at her. Standup goes fine, everyone sounds busy, and yet almost nothing reaches "done." Marcus is half-into the route-caching work, also poking at a map bug, also reviewing Jamie's pull request, also scoping next month's offline mode. Four things, all started, none shipped.

She'd seen this exact pattern in her old life. A wedding where the florist, the caterer, and the band all started setting up at once in a room too small to hold them, and nobody could finish because everyone was in everyone's way.

So she does the simplest possible thing. She opens a board.

Kanban is a flow-based agile approach: instead of fixed sprints, work moves continuously across a board, left to right, through columns that represent the stages of the work. The classic three are To Do → In Progress → Done. Each task is a card, and the card gets pulled into the next column when someone is ready to work on it. (The format you've probably seen — Trello popularized exactly this style of board.)

Renata adds every in-flight task as a card and projects the board on the wall at standup. For the first time, the squad sees the same picture: a crowd of cards jammed in "In Progress," and "Done" almost empty.

Kanban doesn't speed the team up by pushing harder. It speeds them up by making the work visible so the team can fix its own flow.

The name comes from Toyota's factory floor, where kanban (Japanese for "signboard") were cards that signaled when to make more of something — pulling new work only when there was real capacity. That idea survived into software almost intact.

Lesson 6.2 — Two pillars: see the work, and cap it

Renata's board does two jobs, and they're worth naming separately because the second one is the part most people skip.

The first pillar is visualize the work. When every task is a card in a column, a bottleneck stops being a vague feeling and becomes a thing you can point at. The pile-up Renata saw — six cards stuck in "In Progress," "Done" gathering dust — is the board telling her where the work is jamming. No status meeting required; you read it off the wall.

The second pillar is the one that changes behavior: limit work in progress (WIP). A WIP limit caps how many cards are allowed to sit in a column at the same time. Renata writes a small number at the top of the "In Progress" column: 3. That's the most cards that column can hold.

It sounds backwards at first. Marcus says it out loud in standup: "So you're telling me to do less at once?" Yes. Exactly that.

Stop starting, start finishing.

That phrase is the heart of Kanban. When the "In Progress" column is full at 3, nobody is allowed to pull a fresh card from "To Do." If you want to start something new, you first have to help finish something already in flight — review it, test it, unblock it, push it into "Done." The limit forces completion before it allows new starts.

Marcus, juggling four half-done things, was the living argument for the limit. Each half-done task carries a hidden cost: time lost switching between them, work that rots while it waits, a bug nobody catches because attention is split four ways. Capping WIP doesn't make anyone lazier; it makes the team finish what it touches. Within two weeks, "Done" at Cartwheel is filling faster than it ever did when everyone was "busy."

Lesson 6.3 — When flow beats sprints

So why would Renata reach for a Kanban board instead of the two-week Scrum sprints she set up back in Topic 5?

Because some work doesn't fit a sprint. Scrum asks you to commit to a fixed batch of work for two weeks. That works beautifully when you can plan a chunk ahead. It works badly when work arrives unpredictably and has to be handled now.

Picture Cartwheel's support-and-operations rotation: a courier reports the app crashing on launch, a delivery-route calculation comes out wrong, a partner needs a data export today. You can't tell a courier with a broken app "we'll plan that into next sprint." That stream of work is continuous and unpredictable, and Kanban has no fixed sprints — cards just flow across the board as they arrive and get pulled when there's capacity. That's why support teams, operations teams, and maintenance teams so often run Kanban: the rhythm matches reality.

Plenty of teams don't choose one or the other. They blend them. Scrumban keeps Scrumlike pieces — a regular planning cadence, a standup — while using a Kanban board and WIP limits to manage the day-to-day flow. Renata ends up here herself: the driver-app squad plans features in sprints, but her separate bug-and-support queue runs as pure Kanban. Same project manager, two tools, matched to two kinds of work.

There's no purity test to pass. The board is a means, not a badge.

Lesson 6.4 — Waterfall isn't the villain

Tomás, the engineering director, drops by Renata's desk with a question that has an edge to it. Cartwheel is bidding to integrate with a regional government's logistics system, and the contract spells out fixed requirements, fixed milestones, and a fixed compliance audit at the end. "Your agile boards," he says, "how do those survive a contract like this?"

Good question. They mostly don't — and that's fine, because this is what the older approach is for.

Waterfall is the traditional method where the phases run in strict sequence: requirements → design → build → test → release. Each phase is fully completed before the next one begins, like water falling from one step down to the next and never back up. It leans on heavy up-front planning and assumes the requirements are nailed down before the build starts.

Waterfall earned a bad name in software for a real reason: software requirements change, and if you build everything before anyone tests it, you can reach the very end and discover you built the wrong thing. Expensive lesson, learned late.

But waterfall is not a mistake to be ashamed of. It is the right choice when three things are true: the requirements are fixed and well understood, change is costly, and predictability matters more than flexibility. A bridge. A pharmaceutical batch. A government integration with a compliance audit bolted to the end. You do not want to "iterate" on a bridge.

Renata tells Tomás the honest answer: the government integration should run largely waterfall — fixed requirements signed off, clear phase gates he can report upward — while the driver app keeps its agile flow. In practice she'd still build iteratively inside those gates, shipping the integration in working increments between checkpoints rather than as one big-bang build at the end; that's the hybrid she met one lesson ago, not a contradiction. The waterfall structure governs the contract and the audit trail; the iterative build keeps the engineers from discovering a defect only at the final test. The mature move is knowing waterfall is a tool in the kit, not a relic to sneer at — and that "waterfall" rarely means "no iteration anywhere."

Lesson 6.5 — Choosing on purpose, not by tribe

By now you can feel the real skill forming. The skill is choosing the approach that fits the situation instead of defending a favorite, not memorizing Kanban.

Hold the question in plain terms. Are the requirements fixed and well understood, or fuzzy and likely to change? Is change cheap and feedback valuable, or expensive and risky? Do you need predictability above all, or adaptability above all?

If the work is…	Reach for…	Because…
Uncertain, evolving, feedback helps	Agile (Scrum or Kanban)	Increments and feedback reduce the cost of being wrong
Fixed, well-understood, change is costly	Waterfall	Up-front planning buys predictability when change is risky
A mix of both	A hybrid (e.g. Scrumban, or phased-agile)	Real projects rarely sit at a pure extreme

The trap to avoid is the zealot — the person who has decided one method is The Way and forces it onto every project regardless of fit. The all-agile zealot who tries to "sprint" a fixed-scope compliance contract. The all-waterfall zealot who demands a 200-page spec before a tiny experimental feature. Both cause the same damage: they serve the method instead of the goal.

Frameworks serve the goal of delivering value. The goal does not serve the framework.

This is what it means to be methodology-aware, not dogmatic. You understand the principles behind each approach — why WIP limits work, why phase gates exist — and you reach for whichever one helps the team deliver. That flexibility is exactly what separates a project manager who has read about frameworks from one who can actually run real work.

Worked example — Cartwheel, three streams, three approaches

Cartwheel's quarter lands three very different bodies of work on Renata's plate at once. Watch her match each to its approach instead of forcing one method across all three.

Stream one: the driver app's new features. Requirements are evolving — Priya, the Product Owner, is still learning from users what drivers need, and feedback after each release reshapes the next. Renata runs this in Scrum: two-week sprints, a backlog Priya owns, increments tested with real couriers. Uncertain, feedback-rich work, so agile fits.

Stream two: the bug and support queue. This work arrives unpredictably and can't wait for a sprint boundary — a crash today, a bad route tomorrow. Renata runs it as pure Kanban: a board with a WIP limit of 3 on "In Progress," cards pulled as capacity frees up. When Jamie, the QA engineer, flags a card stuck three days, the board makes it obvious and Renata swarms the squad on it. Continuous flow, so Kanban fits.

Stream three: the government logistics integration. Fixed contract, fixed milestones, a compliance audit at the end, change formally costly. Renata runs this largely waterfall — requirements signed off, then design, then build, then test, then release — with phase gates that give Tomás the clean dates and risk picture he reports upward. But she still builds iteratively inside the gates, delivering the integration in tested increments between checkpoints so a defect surfaces early rather than at the final audit. The phase gates govern the contract; the iterative build de-risks the engineering — the same hybrid instinct as stream one, just wrapped in waterfall's predictability. Fixed and change-averse on the outside, so waterfall frames it.

Three streams, three approaches, one project manager. When Marcus grumbles that "this isn't how agile is supposed to work," Renata's answer is the whole topic in a sentence: the methods exist to help Cartwheel deliver, and she'll use whichever one delivers.