The Scrum vs Kanban question comes up in almost every training session. It is entirely understandable — both appear on job descriptions, both involve boards and cards and some notion of iteration, and the agile world does a poor job of explaining how they relate. So let us be direct about it.

The comparison is based on a misunderstanding of what the Kanban Method actually is.

What the Kanban Method actually is

The Kanban Method is not a delivery framework. It is a method for catalysing evolutionary change and improvement within an organisation. Its primary principle — "start with what you do now" — is the clearest possible statement that it is not a replacement for anything. It is an overlay. A way of making your current system more visible, more manageable, and more open to improvement.

This is meaningfully different from Scrum, which is a specific framework with defined events, roles, and artefacts. Scrum asks you to restructure how your team works. The Kanban Method asks you to look honestly at how you are already working and improve from there.

The three Change Management principles

The Kanban Method has three change management principles that explain its logic:

Start with what you do now. No new roles, no new ceremonies, no imposed restructuring. The starting point is your existing process, mapped as it actually functions rather than as it is supposed to function. This reduces the resistance that typically greets change initiatives, because nothing is being taken away.

Gain agreement to improve through evolutionary change. The commitment required is modest: agreement that improvement is worthwhile, and willingness to engage with it incrementally. This is a considerably lower bar than the commitment required to adopt Scrum, which asks teams to reorganise their work, adopt new roles, and operate on fixed time horizons.

Encourage acts of leadership at all levels. Improvement is not a management directive in the Kanban Method — it is an invitation to everyone in the system to contribute observations and ideas. This tends to produce more sustainable change than top-down mandates because it builds ownership.

What this means for the Scrum vs Kanban question

If you are already using Scrum, the Kanban Method is not a competitor. You can apply Kanban thinking to your Scrum process — making the flow of work more visible, identifying where WIP is building up between ceremonies, improving the health of your backlog — without abandoning any of the Scrum structure you have built.

If Scrum is not working for you — if the ceremonies feel like overhead, if the sprints are not producing the predictability you hoped for, if the team is resistant — the Kanban Method's "start with what you do now" principle offers a way to improve without the friction of another major change initiative.

The more useful question than "Scrum or Kanban?" is: "What is not working in how we manage our work right now, and what is the most direct route to improving it?" The answer might involve Scrum, the Kanban Method, or both. It will not be served by treating them as mutually exclusive options in a competition they were never designed to be in.