Kanban vs Agile: Is Kanban Actually Agile?
The Answer
Kanban vs agile compares a method against a philosophy, so the two are not really rivals. Agile is a set of values from the 2001 manifesto, and it prescribes no practices at all. Kanban is a specific method for managing flow: visualise the work, limit work in progress, measure how long things take, improve from there. Most teams running kanban are working in an agile way, which is why “agile kanban” is a normal phrase rather than a contradiction. The honest caveat is that kanban predates agile by about fifty years and came from Toyota’s factory floor, so it carries lean DNA rather than agile DNA, and a few of its ideas sit awkwardly against how agile is usually practised.
Is Kanban Agile?
Kanban is agile in practice and lean by origin. Judged against the four values in the Agile Manifesto it scores well: it favours responding to change over following a plan, since a kanban queue can be reordered on any morning without breaking a commitment, and it puts individuals and interactions ahead of process by prescribing almost no process of its own. Flow metrics measure finished work. Plan compliance goes unmeasured, which is very much the agile instinct.
Lineage is where it differs. Taiichi Ohno built the original kanban system at Toyota in the late 1940s to control inventory between production stages, roughly half a century before seventeen people met at a ski lodge in Utah and wrote the manifesto that gave agile its name. David Anderson adapted the method for knowledge work in the mid 2000s. The agile community took it up because the fit was good, and not because anyone had designed it for them.
Almost everyone answers “is kanban agile” with a yes. The footnote is that kanban would work perfectly well inside an organisation that had never heard of agile, which is not something you could say about scrum.
Kanban vs Agile: What Each One Actually Is
| Agile | Kanban | |
|---|---|---|
| Type | Philosophy, four values and twelve principles | Method for managing flow |
| Origin | Software, 2001 | Toyota manufacturing, late 1940s |
| Prescribes practices | No | A few: visualise, limit WIP, measure flow |
| Prescribes roles | No | None |
| Prescribes iterations | No | None |
| Can be used alone | Not really, it needs a method | Yes |
| Applies to existing process | Not a process itself | Designed to be laid over one |
The last row catches people out. Kanban is unusual among agile-adjacent methods in that it never asks you to adopt a new process: you draw the process you already run, cap how much of it happens at once, and improve from there, which is why a kanban rollout disturbs a team so much less than a scrum rollout does. No new titles. No new calendar. The kanban method covers that starting position in more detail.
What Does “Agile Kanban” Mean?
Agile kanban, or kanban agile methodology if you prefer the longer version, usually means kanban used for knowledge work in an agile context, as opposed to the manufacturing version it descended from. The phrase distinguishes a software team’s board from a signal card on a factory line. Both are genuinely kanban.
So what is kanban in agile, concretely? A board, some caps, and a habit of measuring. An agile kanban board carries four things:
- Columns for the stages work moves through, drawn from your real process rather than a template.
- Cards for individual work items, one per thing that can be finished independently.
- WIP limits on the columns where work collects, which is the part that changes behaviour.
- Flow metrics underneath, so improvements can be measured instead of guessed at.
Take away the third and fourth and what remains is a task board with an agile label. Plenty of teams call that kanban board agile and leave it there, and the board still helps, though it is doing far less work than it could. If yours has no caps on it, WIP limits is where the value is hiding.
Where Kanban and Agile Disagree
Two genuine points of friction, both worth knowing before someone raises them in a retrospective.
Estimation and commitment. Agile as commonly practised leans on estimates, story points and iteration commitments. Kanban is sceptical of all three and prefers forecasting from measured cycle time. Neither position is unreasonable, and a team can hold both, but the arguments do happen.
Iterations. A large part of the agile world treats the time-boxed iteration as fundamental. The kanban method in agile settings treats it as optional and frequently unhelpful, particularly where work arrives unpredictably. Which is the substance behind most agile vs kanban arguments, and behind most kanban vs scrum debates too, since scrum is what people usually mean by agile.
There is also a definitional argument that surfaces periodically: whether kanban is a method, a framework, or merely a set of practices. Kanban’s own literature calls it a method and is explicit that it is not a software development lifecycle. In day-to-day use the distinction changes nothing, and I would not spend a retrospective on it.
Agile vs Scrum vs Kanban: Sorting the Three Terms
These three get compared as though they sit at one level, which is where most of the confusion starts.
- Agile is the philosophy. It tells you what to value and nothing about what to do on Monday.
- Scrum is a framework built on that philosophy. It prescribes roles, events and a fixed time box.
- Kanban is a method you apply to whatever process you have. It prescribes visualisation, WIP limits and measurement.
Agile is the category. Scrum and kanban are two of the things inside it, so comparing those two is a fair fight, since both answer the same question about how work actually gets managed day to day. Comparing agile against either compares a philosophy with an implementation of it, which is why someone asking about “kanban vs agile” is nearly always deciding kanban vs scrum. Want a middle path? Scrumban is the hybrid.
Does Kanban Follow the Agile Principles?
Mostly, and the exceptions are interesting. Of the twelve principles behind the manifesto, kanban supports the majority directly. Continuous delivery of valuable software is what flow is for. Welcoming changing requirements is easier without a sprint commitment. Sustainable pace is what a WIP limit enforces, since a capped column is a hard stop on overloading people. Simplicity, defined in the manifesto as maximising the work not done, is close to kanban’s core argument.
The principle kanban handles differently is delivering working software on a regular cadence of a couple of weeks to a couple of months. Kanban delivers when items are done, which can be more often than that or less, depending on the work. Teams that need a predictable release rhythm layer one on deliberately rather than getting it from the method.
FAQ
Is kanban a subset of agile?
Broadly yes in how the industry uses the terms, though it predates agile and can be applied outside it. Manufacturing teams have run kanban for decades without any reference to agile software development.
Can you be agile without kanban or scrum?
Yes. Agile is a set of values, and teams practise it through several frameworks including XP, SAFe and their own hybrids. Kanban and scrum are the two most common, not the only options.
Which is more agile, kanban or scrum?
Kanban adapts faster to change, since priorities can shift on any day rather than at a sprint boundary. Scrum builds in more structured inspection through its events. Both satisfy the manifesto, so the question is less about agility and more about which failure mode you would rather have.
Is a kanban board an agile board?
An agile board is any board a team uses to visualise work in an agile process, and a kanban board qualifies. The label describes the context of use, so a scrum board is equally an agile board.