Kanban and Scrum: I’m confused!

Scrum is huge. It is the pre-eminent Agile method by far, in use by 75% of Agile teams. It has been in existence for 20 years and its core description has been finely honed. Gartner says the majority of projects are being run using an Agile method. Jeff Sutherland reports that there are 600000 Scrum jobs advertised.

Kanban first emerged as a Lean-Agile method less than ten years ago. Five years ago it was hardly known. And yet already 24% of Agile teams claim to be using Kanban.

Why this rapid growth of Kanban adoption? Is Scrum wrong or broken?

I can offer only my own opinion…

As an Agile practitioner I have taught, mentored and coached Scrum teams for more than seven years and Kanban teams for only three, so my skills and knowledge are certainly biased. I still deeply believe that Scrum as a framework “bakes in” a wealth of good practices that support Agile principles. I believe we are still discovering how good this pattern really is as we learn more about brain science and leadership, just to name two fast-advancing knowledge areas.

Yet the Kanban method offers us some fresh practices that are especially helpful in some circumstances. So much so that I am introducing some teams directly to Kanban these days.

So what are the factors that lead me to apply Kanban over Scrum? Don’t treat this as an exhaustive list or as a “final” answer. Rather use it to have a conversation with your peers or your Agile mentor.

  • If a team is doing more reactive work than planned items, Kanban’s lack of fixed iterations may be helpful. An example is software support. But beware of separating support and development teams, as this can reinforce an us-and-them culture.
  • If your team has a mix of skills that makes it really difficult for the whole team to collaborate on items, Kanban may enable a board design that visualises this better. An example is an IT infrastructure team. But beware of reinforcing silos of knowledge and a non-collaborative mindset.
  • If your team has a mix of work types that must constantly be prioritised against one another, including both reactive and predictable work, Kanban’s classes of service may help you. An example is a single team that must field “popcorn” requests from a multitude of stakeholders that makes planning even a week or two ahead too difficult. But beware that this is not simply an excuse for a lack of discipline on the part of stakeholders…or even team members.
  • If your team’s customers would rather have a predictable turnaround time for a piece of work than have a release plan for a “project”, Kanban’s metrics may be a good fit. But beware that a Kanban board is not simple to operate effectively.
  • If your team has struggled to get Scrum to work for them, you may be tempted to deploy Kanban as a “Scrum failure pattern” (or vice versa). We see plenty of this. In the majority of cases, it hides the underlying unwillingness to take the tough and unpopular actions that are needed to overcome deep dysfunctions in the organisation. So beware of seeing Kanban or Scrum as an easy way out.
  • Lastly, Scrum has helpful mechanisms “baked in” to many of the “process” problems that teams experience. With Kanban, your team will need to install these themselves. So Kanban is not for sissies and you will need to develop a deep understanding of how to improve Lean processes.

As an Agile practitioner what should I do?

As the well-used metaphor goes, if you have only a hammer, then everything looks like a nail. So I believe it is important to add tools to your Agile toolbox. And, importantly, learn how to use them and practise their use.

So, as an experienced Scrum Master I suggest you read some books, attend Kanban training and find a team to practice your new skills with.

Remember that this is only my opinion…


  1. MarkPearl August 6, 2013 Reply

    Agree with these points. Great post.

    View Comment
  2. Yuvaan Gugrajah August 6, 2013 Reply

    Unfortunately the author appears to see Kanban as an alternative to Scrum which goes against what the Kanban system really is. Also, although probably unintended, there is a possibility that readers of this article may assume Kanban is more suited to support type work and not suited to long term projects in terms of predictability and work item types. Both of which are commonly held misconceptions. In terms of “baked in processes” Kanban actually makes things like limiting work in progress, swarming, definition of done etc, more explicit and easier to implement.

    View Comment
    • Author
      Peter Hundermark August 21, 2013 Reply

      Hi Yuvaan,

      Thanks for your comments. I’d be grateful to know more about “what the Kanban system really is”. I agree a Kanban implementation can provide predictability through cycle time as Scrum does through velocity. Kanban certainly makes limiting WIP explicit—definitely a good thing. I’m unsure how swarming or DoD are more explicit or easier; in my observation the lack of an explicit cross-functional team slows the rate of improvement. I’d love to hear more about your experience.


      View Comment
      • Yuvaan Gugrajah August 21, 2013 Reply

        Hi Peter

        Much of my understanding is based on David Anderson’s literature.

        Firstly, to tackle the support vs project work suitability of Kanban, taking the Cynefin model into account, IT Ops Support work falls into the Simple and Complicated domains. Since demand is mostly due to “failure demand”, IT Ops is more of a push/reactive system. Big projects on the other hand fall into the Simple, Complicated and Complex domains. Here demand is “value demand” and can be more pull based and proactive. So while Kanban’s mechanics of decoupled cadences & single-piece flow are alluring in IT Ops, the natural territory for Kanban is actually with major projects.

        My thoughts around the “Kanban System” stem from the 3 principles for applying Kanban:

        1. Start with what you do now

        2. Agree to pursue incremental, evolutionary change

        3. Initially, respect current processes, roles, responsibilites & job titles

        This implies that you would overlay what you are doing in a Scrum context with a Kanban philosophy (Kaizen – evolutionary change), not “replace” Scrum (Kaikaku – revolutionary change). My concern is that it is too easy for teams new to Kanban to assume that it’s all about the “board” when Scrum is compared to Kanban. But there’s much more to the philosophy than adopting a board. Another concern is that management start to wonder if Kanban is just another fad because they have just sent all their employees on Scrum training and now everyone is talking about Kanban. Whereas the message should be that we are adopting a Kanban philosphy, not overhauling the system. In essence, you can have a “Scrum board” with all of your Scrum ceremonies and still begin applying “Kanban”.

        As David says in one of his presentations: “Kanban systems do not stand alone as process solutions. A Kanban system is something that is overlaid on an existing process”. (Yes, technically Scrum is a framework 😉 )

        The 5 core practices for successful Kanban adoption are:

        1.Visualize Workflow

        2.Limit Work-in-Progress

        3.Manage Flow

        4.Make Process Policies Explicit

        5.Improve Collaboratively

        Clearly all 5 are to some degree already part of Scrum. However, having an explicit WIP limit is easier to follow for the team than a vague limit on how many features should be in progress by the team as is the case with just Scrum alone. This WIP limit in turn facilitates swarming in a far more rigid way than with Scrum alone. As far as DoD goes, what we have found is that having the explicit process policies at each stage of the development flow contributes to having DoD met at the end of flow, with no comebacks. With Scrum alone we have always struggled with the DoD being met.

        I’ve tried to keep this as concise as possible but each discussion point is a huge discussion in itself, so I hope it makes sense.



        View Comment

Leave a reply

Your email address will not be published. Required fields are marked *