Kanban vs Scrum vs Agile

by on July 27, 2015 · 11 comments

When inflexible and wasteful software development processes are making your organization inefficient, it’s time to introduce an agile methodology. Kanban vs Scrum then becomes an essential question: Which agile software development methodology is better suited for my own situation? And is Kanban agile? What about Scrum vs agile? Confusion is spreading… Let’s have a look how to sort out all those questions.

Scrum – A Fundamental Shift

Scrum is a well defined process framework for structuring your organization. Introducing Scrum is quite a change for a team not used to agile software development: They have to start working in iterations, build cross-functional teams, appoint a product owner and a Scrum master, as well as introducing regular meetings for iteration planning, daily status updates and sprint reviews. The benefits of the Scrum methodology are well understood: Less superfluous specifications and less hand overs due to cross-functional teams, more flexibility in roadmap planning due to short sprints, etc. Switching your organization to use Scrum is a fundamental shift which will shake-up old habits and transform them into more effective ones.

Scrum Leverages Commitment As Change Agent

The initial introduction of Scrum is not an end in itself. Working with Scrum you want to change your teams’ habits: Take more responsibility, raise code quality, increase speed. As your teams commit to sprint goals, they are intrinsically motiviated to get better and faster in order to deliver what they promised. Scrum leverages team commitment as change agent. It’s amazing to see how much teams demand from themselves – often way more you as a manager ever dared ask for.

Kanban – Incremental Improvements

The Kanban methodology is way less structured than Scrum. It’s no process framework at all, but a model for introducing change through incremental improvements. You can apply Kanban principles to any process you are already running (even to Scrum 😉 ). In Kanban, you organize your work on a Kanban board. There you have states which every work item passes through from left to right. You pull your work items along through the in progress, testing, ready for release, and released columns starting from the left hand side based on the allocated capacity of each of the columns. And you may have various swim lanes – horizontal “pipelines” for different types of work. The only management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. Nothing else needs to be changed to get started with Kanban.

Kanban Leverages Work In Progress (WIP) Limits as Change Agent

For every column (state) on your Kanban board you should define a “Work In Progress”-Limit (WIP Limit). The WIP limit tells you how much work items are allowed to stay in a certain state. If the state is “full”, no new work can enter that state. The whole team has to help clear the filled up state first. That way your team will find out about bottlenecks in the progress simply by looking at the Kanban Board and is challenged to change the way they work to avoid such bottlenecks in the future. In that way, the WIP limit acts as change agent in Kanban.

Kanban vs Scrum

Looking at both agile software development methodologies it should be more clear what to introduce when: If your organization is really stuck and needs a fundamental shift towards a more efficient process, Scrum seems to be more appropiate. If you already have working processes, which you want to improve over time without shaking up the whole system, Kanban should be your tool of choice.

And Scrum vs Agile?

Asking for the differences between Scrum vs Agile or Agile vs Scrum is like asking for the differences between “Water” and “Ice”. Ice is water in a specific physical state. The same could be said about Scrum vs Agile. Scrum is agile in a specific shaping. It is an agile process framework. Scrum and Kanban in software development are both specific shapings of an agile software methodology. While Scrum vs Kanban or Kanban vs Scrum is comparing two agile methodologies, Scrum vs Agile is comparing a concrete example with its fundamental principles.

Did you enjoy this article? Get new articles for free by email:


  1. says

    Matthias, that does simplify things very nicely. Thanks for the overview.

    One very visible and notable difference is that Scrum has the Sprint Planning meeting and the Spring Retrospective. They demand customer involvement in a very pointed way. It’s rather easy for the customer to ignore “the board” with the attitude that it’s just for the geeks to play with. The customer really can’t ignore Scrum because it starts and ends with the customer.

  2. says

    Mark, thanks for pointing this out. It’s a good example showing that Kanban is not a process framework like Scrum. Exactly such things like customer involvement (and many more) have to be defined separately. It’s even a good idea to run Scrum and improve it over time using Kanban (sometimes this is called “Scrumban”)

  3. says

    a very nice and interesting summary. The introduction of Kanban to our company worked smoothly and the result has been efficent as expected. There was no change management needed as this is easy to implement and to understand with an immediately outcome of results. Have you also some more experience and some advise how to efficiently upgrade from Kanban to Scum (Kanbum?)?

  4. says

    Hi Matthias,
    Enjoyed reading this summary of Scrum and Kanban. It’s nice to see concise well written paragraphs.
    Wanted to point out though that Kanban is a pull system versus a push system, instead of, “You start left with the Backlog, and push your work items along through the in progress”, it should read, “You start on the right hand side of the board and pull work items through based on the allocated capacity”.
    Dominica DeGrandis

  5. says

    Hi Matthias,

    I have published a similar post before, “Scrum to Kanban“. The post lists the flaws in Scrum, and then talks about Kanban and how to migrate from Scrum to Kanban.

    I think your article is excellent as a comparison between the two, and I would like to republish it on PM Hut. Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.