This site only uses technical cookies required for it to work: no tracking, no profiling. Cookie Policy

Skip to content
All terms

What is Kanban, and how is it different from Scrum?

A workflow management method: you make visible what is open, and you cap how much is allowed to be open.

Kanban is a workflow management method built on two gestures: making visible everything that has been started and not yet finished, and putting an explicit cap on how many things may be open at once. The word is Japanese and names the card that on a Toyota floor authorized the next piece of work: no free card, no new part. Applied to knowledge work by David J. Anderson in 2010, it keeps that pull logic. The operating rule is that new work enters only when something leaves, which shifts attention from how busy people are to how long it takes between a customer's request and delivery. Those are two different numbers, and improving the first regularly makes the second worse, and the second is the only one the customer perceives and judges the service on.

Why it is not Scrum

Where the sprint prescribes roles, fixed-length iterations, events and a commitment taken at the start, here there is none of that: no new roles to create before you begin, no fixed-length iterations, no estimates required, and it explicitly starts from the process you already run instead of replacing it. Two roles emerged later, service delivery manager and service request manager, but they stay optional. It is a method of gradual change, not an organizational framework, which is why it can be adopted without reorganizing anyone. The flip side is that it brings no discipline with it: if the problem is that nobody sets priorities, Kanban makes that visible and nothing more.

A concrete example

A five-person support desk takes requests from three different channels and closes tickets as they come. The board shows twenty-three open items for five people. The cap is set where the team already is and lowered to two per person as open items close; the incoming queue waits until a slot frees up. The first weeks feel slower, because it becomes visible that somebody is waiting, which used to be hidden inside an inbox. Then average time to close falls. What was removed is not work, it is the time work spent standing still.

Why it matters for decision-makers

It is the intervention with the best ratio of cost to result I know, because it needs no licenses, no reorganization and no ongoing consulting: it needs the willingness to let some things wait explicitly rather than have everything started. The resistance it meets is always cultural and never technical, because one idle person looks like waste while twenty-three idle pieces of work do not. One warning: the number of items on the board is not a productivity measure, and using it as one reproduces exactly the failure described by Goodhart's law.

Frequently asked questions

Not necessarily: Scrum prescribes roles, iterations and events, Kanban imposes none of the three, and it starts from the process you already run. Many teams combine them, keeping Scrum's events and adding a cap on open work. If the problem is the time requests spend standing still, though, Kanban alone addresses it more directly.

There is no number that holds everywhere, and anyone offering one deserves suspicion. Start low, typically one or two per person, watch where the queue forms, and adjust. The limit exists to surface the bottleneck, so if it never creates waiting anywhere it was set too high.

No. A whiteboard with sticky notes works, and in the first weeks it works better, because it makes the scarcity of slots physical. A digital tool earns its place when people do not share a room, or when you need historical timings to see where the waiting accumulates.
  • Lean software development · Lean manufacturing principles brought to software: what gets eliminated is waiting and unfinished work, not people.
  • Scrum · A development framework of fixed-length cycles, three accountabilities and five events: useful only if the product owner really decides.
  • Agile · Organizing development in short cycles, re-deciding priorities: it works only if the contract lets the scope change.
  • Team Topologies · An organizational design model for software: four team types and three interaction modes, sized by cognitive load.
  • Goodhart's law · When a metric becomes the target, it stops measuring: what Goodhart's law implies when you accept an AI project.

A term that hits close to home? Let's talk.

CONTACT ME