Kanban: A Visual Approach to Agile Project Management

Kanban: A Visual Approach to Agile Project Management

Kanban Is Not a Task Board

This matters because most teams think they’re doing Kanban when they’re doing something much simpler: a visual task board. Task boards are useful. Kanban is a system for managing flow, and most “Kanban boards” I’ve seen don’t actually enforce the one property that makes Kanban work: work-in-progress limits.

Without WIP limits, you have a board. With WIP limits, you have Kanban.

Why This Distinction Matters

A task board shows you what people are working on. Kanban shows you where work is flowing well and where it’s stuck. These are different questions with different implications.

Here’s what happens without WIP limits on a typical software team: every developer has four or five items “in progress” simultaneously. They’re context-switching constantly. Items sit in “In Progress” for two weeks because there’s always something more urgent to pick up. Nobody finishes anything completely before starting something new. The board is full of in-progress cards that are effectively stalled.

Here’s what WIP limits force: when the “In Progress” column hits its limit of three items, you cannot start new work. You must finish something first. This constraint feels uncomfortable — especially for developers who want to start the interesting new thing — and it is productive discomfort. It exposes blockers that were previously hidden by the illusion of activity.

The Origins: Why Toyota’s Supermarket Matters

Taiichi Ohno’s insight at Toyota in the 1940s was elegant: instead of pushing production based on what the factory could make, pull production based on what customers actually ordered. The supermarket model — restock only what’s consumed — eliminated excess inventory and exposed production problems that overstock had hidden.

David Anderson adapted this for software in the early 2000s. The parallel is direct: instead of pushing work onto developers based on what’s in the backlog, pull work based on capacity. WIP limits are the mechanism. When you can’t start new work until something finishes, you naturally expose where the real bottlenecks are.

The Core Properties of Kanban (Not Just the Board)

Visualize the workflow — this is the easy part. Map your actual process stages into columns. Not your ideal process; your actual one. If there’s a “waiting for review” stage that work sits in for days, that’s a column. Hiding it doesn’t make it go away.

Limit work in progress — set a maximum per column. The right number is determined empirically. Start with a limit that feels slightly too tight (you’ll know when things get blocked frequently). Adjust based on what you observe. A common starting point: WIP limit = (team size × 1.5) for the main development column.

Manage flow — track how long items take from start to finish (cycle time). Track how long they take to arrive at done from creation (lead time). These numbers tell you more about system health than velocity ever will.

Make policies explicit — what does it mean for a card to move from “In Progress” to “In Review”? What makes a card “Done”? Teams that can’t answer these questions clearly are moving cards around based on vibes. Write the policies down and put them on the board.

Implement feedback loops — Kanban doesn’t prescribe specific meetings, but you need regular touchpoints to review what the flow data is telling you. Daily standup structured around the board (discuss blocked items, don’t just report status) and weekly metrics review are the minimum.

Improve collaboratively — the data the system produces should drive process changes. If review is consistently the bottleneck, change the review process. If cycle times are high, examine why.

Kanban vs. Scrum: The Honest Comparison

Scrum suits teams with clear sprint goals and work that can be decomposed into approximately equal-sized chunks. The cadence of planning, review, and retrospective provides structure that works well for teams building discrete product increments.

Kanban suits teams whose work arrives continuously in varying sizes and types, where rigid sprint commitments don’t fit the workflow. Support teams, operations teams, and teams with high interrupt-driven work often find Kanban more natural than Scrum.

Neither is universally better. The worst outcome is running “Scrum-ban” — having sprint ceremonies and a Kanban board but neither the discipline of Scrum commitments nor the flow optimization of Kanban. This is depressingly common.

Choose based on your actual workflow, not on what sounds more modern.

Where Kanban Fails

Teams set WIP limits too high. If your limit is 10 and you have 8 developers, the limit isn’t actually limiting anything. WIP limits work by constraining behavior. If they’re never hit, they’re not doing anything.

Teams treat the board as a reporting tool rather than a management tool. If the board is only updated during standups to give the appearance of progress, you’re wasting your time. The board should reflect reality in real time so that blockers are visible when they happen, not 24 hours later.

Teams don’t analyze flow metrics. Most Kanban implementations I’ve seen use the board but ignore cycle time, throughput, and lead time data. This data is what tells you whether your process changes are actually working. Without it, you’re making changes based on feelings.

Teams add columns without removing work. Every column transition is overhead. Kanban boards sometimes accumulate stages until every card goes through nine states and takes a week to get from one end to the other. If a stage is adding time but not value, collapse it.

Getting Started Without Getting It Wrong

The most useful first step isn’t building the board. It’s mapping your actual workflow — every stage a piece of work goes through from “someone has an idea” to “it’s in production.” Do this with your team, not by yourself. The conversation about what the stages actually are is more valuable than the board itself.

Then add one WIP limit — just on your main development column. Watch what happens. Where do things pile up? What gets blocked? That data tells you where to look next.

The goal of Kanban isn’t a pretty board. It’s a system that makes problems visible fast enough to fix them before they become disasters. If your board is showing you problems you didn’t know you had, it’s working. If everything always looks green, you’re not using it correctly.