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…