Why Kanban Works — and How to Know If Your Team Is Ready for It

Most teams adopt Kanban because someone read a blog post. The smarter question is whether the problems Kanban solves are actually the problems your team has.

There is a moment most teams recognise, usually around the time they have more than eight or nine people. Work is getting done — emails are sent, features ship, clients are managed — but nobody has a clear sense of what everyone else is doing. Projects pile up. Things get promised and then quietly forgotten. You spend twenty minutes before every meeting figuring out where a piece of work actually is. The answer, usually, is "somewhere."

That is the problem Kanban was designed to solve. Not the problem of setting strategy, or hiring the right people, or building a culture — but the specific, grinding, operational problem of knowing what your team is working on and what is getting in the way.

It is a surprisingly humble tool for something that has attracted so much attention. Kanban does not claim to fix your organisation. It just makes work visible. And it turns out that visibility, applied consistently, changes a remarkable number of things downstream.

Where Kanban actually came from

The word is Japanese — it means "signboard" or "billboard" — and the system was developed by Toyota in the late 1940s as a way to manage inventory in their manufacturing plants. The idea was simple: rather than producing parts on a fixed schedule, the factory would produce them only when a downstream station signalled that it needed them. A physical card — the kanban — would travel back up the line as a request. Nothing was made speculatively. Nothing piled up unnecessarily.

The insight Toyota had, and that software teams later borrowed, is that most inefficiency in a system comes not from people working too slowly, but from the wrong work being done at the wrong time. Too many things started at once. Bottlenecks that nobody notices until it is too late. Work that sits finished in one place while the next step is overwhelmed somewhere else.

Software developers, particularly at companies like Microsoft in the early 2000s, started adapting these ideas for knowledge work. The cards became tasks. The factory stations became stages in a workflow. And the signboard became a board — physical at first, then digital — where anyone on the team could see, at a glance, what was in progress, what was waiting, and what was done.

What a Kanban board actually shows you

A basic Kanban board has three columns: To Do, In Progress, and Done. That is sufficient for many small teams and a fine place to start. But the real value emerges when you start customising those stages to match how your work actually flows — not how you wish it flowed.

A content team might use: Idea, Brief, In Draft, In Review, Scheduled, Published. A software team might break "In Progress" into separate columns for development, code review, and QA. A consulting team might track Discovery, Proposal, Active, Awaiting Client, and Closed. The stages should reflect real handoffs and real waiting times — places where work changes hands, or where it sits until something else happens.

Notice the card in the middle column — the warehouse audit report, eight days in, marked as blocked. In a system without a board, that task might sit for two more weeks before anyone realises it is not moving. Someone is waiting on a third party. Or a decision is needed from a manager who does not know they are the blocker. The board makes the blockage visible. That is most of the work.

The rule that makes it work: WIP limits

If there is one concept that separates teams using Kanban properly from teams who just have a prettier to-do list, it is work-in-progress limits — WIP limits for short. The idea is that each column has a maximum number of items that are allowed to be there at once. When a column is full, you cannot add more work until something moves out.

This feels counterintuitive. Surely being able to put more tasks in progress means more is getting done? It does not. What actually happens when people work on too many things simultaneously is that everything takes longer. Context switching is expensive. Half-finished work creates coordination overhead. And when ten things are "in progress," it is very hard to tell which ones are actually moving and which are just stuck but unmarked.

A WIP limit of three on your In Progress column means that when the fourth thing arrives at someone's desk, someone on the team has to make a decision: which existing task gets completed first? It forces prioritisation. It forces conversation. And it tends to produce faster completion of individual items, even if the rate of starting new items slows.

Kanban versus Scrum: the question teams always ask

If you have spent any time around software teams or modern operations thinking, you have probably encountered Scrum — the framework that organises work into fixed two-week sprints, with planning sessions, retrospectives, and defined roles like Scrum Master and Product Owner. Many teams treat Scrum and Kanban as competing methodologies and feel they have to choose. The distinction is actually simpler than that.

Many teams — especially those that are not pure software engineering teams — find Scrum's ceremony heavy and its fixed-sprint structure awkward to apply to ongoing operational work. Marketing teams, customer success teams, operations teams, and founders managing everything-at-once rarely have work that fits neatly into two-week cycles. Kanban's continuous flow model tends to suit them better.

That said, many teams combine both. They use sprint-style planning cycles for product development while running a Kanban board for the operational and support work that flows in regardless of what sprint you are in. That is a perfectly reasonable hybrid.

The three questions your board should answer in thirty seconds

A Kanban board is most useful when you can look at it and, without talking to anyone, answer these three questions quickly: What is the team working on right now? Where is work getting stuck? Is there anything that should be done that has not been started?

If you cannot answer all three within thirty seconds of looking at the board, it is probably not being maintained properly. The most common failure mode is a board where tasks are created but never moved — it becomes a graveyard of good intentions rather than a live map of actual work. A board that is not current is worse than no board, because it creates a false sense of visibility.

The discipline required to maintain a board is real. Tasks need to move when work moves. Blocked items need to be flagged the moment they stall, not two weeks later. Cards need to have clear owners, and owners need to update their cards. None of this requires a lot of time — a well-run Kanban practice might take five to ten minutes per person per day — but it requires consistency. The teams that benefit most from Kanban are those who treat the board as the source of truth, not as a supplementary record-keeping exercise.

What Kanban does not do

Kanban is not a strategy tool. It will not help you figure out what to work on — only help you manage what you have already decided to work on. If your organisation has a prioritisation problem, or an unclear mandate problem, or a "we start too many projects before finishing old ones" problem rooted in leadership behaviour rather than process, a Kanban board will reveal those problems but not solve them.

It is also not a substitute for good management. A board does not replace one-to-ones, or thoughtful delegation, or clear communication about why certain work matters. Teams sometimes adopt process tools hoping the process will do the relational and organisational work that is actually the manager's job. It will not.

What it will do is reduce the ambient uncertainty that slows most teams down. The questions of "who is working on what," "is this done," and "what should I pick up next" generate enormous amounts of low-value communication in organisations that do not have a shared, visible system. Kanban eliminates most of that noise. And for teams where that noise is the dominant problem, the difference is significant.

How to start — without a three-day workshop

The best Kanban implementations I have seen started small and evolved. The worst ones involved a consultant, a two-day offsite, and a beautifully designed board that nobody used by week three.

Start with your team as it actually is, with the work you actually have. Create three columns: Backlog, In Progress, Done. Spend thirty minutes with your team putting every current work item on a card. Agree on one rule: when you start something, it goes on the board. When it moves, you move the card. Do nothing else for two weeks.

After two weeks, look at the board together. Where did things pile up? What stayed in Backlog that everyone said was a priority? What moved faster than expected? What got stuck and why? Use what you observe to refine the columns and add specificity. Maybe "In Progress" needs to split into "In Progress" and "Waiting on External." Maybe you need a column called "In Review" because that step keeps getting lost. Let the board evolve in response to what your actual work reveals, not in response to what a methodology book says it should look like.

The longer game: flow metrics

Once a Kanban system is running, it generates data that most teams never use. Lead time — the total time from when a task is created to when it is completed — is the most important. If your average lead time for a typical task is twelve days, and you want it to be five, you now have a number to work against and a board that will show you where those extra seven days are going.

Cycle time measures only the active working period, excluding the time a task sits in the backlog. Throughput measures how many items your team completes per week. None of these metrics require special software if you are disciplined about noting when cards are created and when they are closed. And together, they give you a much more honest picture of your team's capacity than any estimate-based planning process can.

Most small and mid-size teams never get here. They use Kanban as a visibility tool — which is valuable on its own — and do not go further. That is fine. But if you find yourself wanting to make commitments to stakeholders about when something will be done, or wanting to understand why some work takes three times as long as expected, the metrics are there when you need them.