Kanban

Ask a team what they are working on and the old answer was "it's in progress." Eight people holding three or four items each means twenty-four things are in progress, and nobody can say how many of them will finish this week. When there is no picture of where work is piling up, there is also no picture of why anything is late.

Monday status meetings kept landing in the same place. Someone would read out twelve items, each owner would say they were almost done, and the following Monday the same twelve items would get the same answer. Four of them were actually stuck, and the reason none of the four could move never made it into the notes. Everyone was busy and nothing was finishing.

Holding more at once feels like it should produce more, but it works the other way around. Switching between three items means reloading each one — remembering where you left off, what the open question was, which file you were in — and that reload cost multiplies with the number of open items. On top of that, nothing has shipped until all three are done, so the person who asked waits three times as long. Finish one and move on, and the same amount of work gets done in the same hours while the first request goes out in three days. The problem is not the total volume. It's the waiting.

The word comes from a factory. When each station pushed finished parts forward, boxes piled up in front of the next station, so the next station started sending a card back saying how much it actually needed and pulling only that. The card was called a kanban, and the word means a signboard you can see. The device did two things: it made the queue of work visible, and it moved the trigger from the front of the line to the back. The idea moved into software development in the late 2000s, where boxes of parts became individual work items and stations became columns on a board.

Inside the framework branch of ways of working, the first fork is whether you cut time or manage flow. Scrum cuts time into fixed lengths like two weeks and picks what goes inside before the cycle starts. Kanban doesn't cut cycles at all. Instead it draws the columns a piece of work passes through on its way out and sets a number for how many cards each column may hold at one time. A column at its number cannot take a new card, so whoever wanted to start something next ends up clearing what is stuck ahead of them. Those twelve "almost done" items sit on the board as eight cards in development and four waiting on review. Where the jam is stops being a claim and becomes a position.

The lean idea that anything not moving toward value is waste sits directly underneath all of this. Lean reads a pile of half-built features as inventory; kanban makes that inventory visible and then caps it.

The terms under kanban fall into four groups: what you draw the flow on (tools), what you forbid on top of it (rules), how you tell whether flow improved (metrics), and where flow stops (problems).

Tools are where the flow gets drawn. A kanban board puts each item on a card and lines the cards up in columns by state. The columns copy the stages a team actually goes through — something like backlog, in development, code review, waiting on acceptance, done. The starting move is not copying someone else's columns but naming the places your own team waits. A waiting stage that has no column of its own can swallow days without anything on the board changing. A swimlane splits the same board horizontally. When incident work and new features compete for the same columns, urgency wins every time, so the lanes separate them and each lane gets its own count.

Rules are what the board forbids. There are two, and they are really one mechanism.

1. Work in progress limit (WIP limit) — the maximum number of cards a column may hold at once. Set development to three and the person reaching for a fourth card cannot open it even with free hands. They help move one of the three that is already there instead. Without this rule the board is a to-do list with cards on it.
2. Pull system — instead of being handed an assignment, whoever frees up pulls the next card. When work is handed out in advance, the board never shows whose queue is backing up, and nobody ends up helping the person who is stuck.

The two rules aim at the same place. A cap is what makes pulling possible, and pulling is what gives the cap meaning. The number itself is hard to get right on the first try, so teams usually start below headcount. Five developers with a development limit of three or four, because a limit equal to headcount simply licenses the old state where everyone holds one item and nobody helps anyone. Run it for a few weeks, raise it by one if people are idle often, lower it by one if cards sit too long.

Metrics tell you whether flow improved. There are four. The first two measure a single card; the last two measure the shape of the whole board.

1. Lead time — from the moment a request arrives to the moment it's done. This is the time the requester feels, so it's the number you make promises with.
2. Cycle time — from the moment someone actually starts working to the moment it's done. The gap between the two is waiting. A lead time of nine days against a cycle time of two means seven days were spent in a queue with nobody touching the item, and what that team needs to fix is how it orders work, not how fast it codes.
3. Throughput — how many cards finish in a given period. A team that ships ten a week with twenty cards queued ahead can tell a requester that their item starts in about two weeks.
4. Cumulative flow diagram — a graph stacking the number of cards in each state over time. A band that gets thicker as time goes on means more is entering that column than leaving it, which makes the jam visible at a glance.

Problems collect the places flow stops. A bottleneck is the slowest stage, the one that sets the pace for everything else. If one person does all the code review, weekly output matches that person's review speed no matter how fast the code gets written. A blocker is a single card that can't move because of some outside condition — waiting on a vendor's answer, for instance. A bottleneck is a property of a stage; a blocker is a property of one card. They're kept apart because the responses differ. You relieve a bottleneck by adding people to that stage or lowering the cap on the column feeding it; you clear a blocker by marking it and naming who chases it each day.

The four groups run in one direction. You need the flow drawn before you can cap it, you need the caps before waiting time drops and the metrics move, and when the metrics don't move you go back and look for the bottleneck. That chain explains why nothing changes for teams that adopt the board and skip the caps. Cards are on a wall now, but the number of things being held at once is exactly what it was.

"Development is at its limit, so don't start anything new — let's clear the review queue together."

The cap has been hit, so the move is to finish what's stuck ahead rather than open more.

"Lead time on this request was nine days and the actual work was two. Seven days it just sat in line."

The delay came from waiting, not from building, so the thing to fix is how requests get ordered.

"We don't run sprints. We manage it on the board and quote dates from weekly throughput."

The team manages flow instead of fixed cycles, and its commitments come from recent measurements rather than from a planning session.

At Pagedeck the inbound support work runs this way. About ten of the questions that reach Sofia each week need an engineer, and since there's no telling when they'll arrive, they can't be packed into a two-week cycle in advance. Theo set up a board and capped the development column at three.

The first two weeks brought complaints, because having free hands and still not being allowed to open a new item felt wrong. Then in the third week nine cards were sitting in the acceptance column. Development wasn't slow — Mia had been batching her acceptance checks. Once she set aside thirty minutes each morning for them, median lead time dropped from nine days to four. The board didn't supply that answer. All it did was show where the nine cards were.

The most common mistake is thinking that using a board means doing kanban. The board is the only visible artifact, and it's also the thing a tool gives you the moment you install it, so the assumption is easy to make. What actually changes the flow is the cap. A board without one is a to-do list with cards on it — the same twenty-four items held at once, now decorating a wall. Left alone, the team spends three months with new tooling and unchanged lead times and concludes that kanban doesn't suit them. What didn't suit them was a cap they never set.

The second is reading kanban as the option without deadlines. Nothing cuts the calendar into cycles, so it sounds like nothing gets promised either. In practice the promise is made differently. Where scrum commits to what fits in the next two weeks, kanban commits from recent lead time and throughput: if the last thirty items mostly finished inside four days, four days is a fair answer for the next request. A team that hears "no deadlines" tends to skip the caps and the measurements too, and what's left is an unmanaged queue. The requester has no basis to ask when, and the team ends up slotting in whatever looks most urgent that morning.