Kanban vs. Scrum

A few months ago I took the Kanban System Design (KMP I) course in Toronto.

My exposure to Kanban goes back to 2004 when I was consulting at CapitalOne. One of the most intelligent people I have worked with, Emma, was using Agile and Lean principles to help her department become more effective. In the consulting engagement with her and my co-worker at the time, Sanjiv, we explored the possibility of an Agile flow approach to work, and I implemented it with one of the teams I was coaching there in 2005. Over the years I've had the good fortune to implement Kanban or Kanban-like approaches at about half a dozen organizations. There were even a couple years when I was teaching a Scrum class that added some modules on Kanban. It has always been an excellent approach, and always led to great improvements in the way the organization works.

Nevertheless, as a long-time Scrum proponent, I have often downplayed Kanban as a serious alternative. Since taking the Kanban System Design class, one of the most important things I have learned **through experience** is how Kanban can be applied to so many more situations than Scrum. The STATIK* exercise opened my eyes, and gave me the framework to decide how to apply Kanban. At BERTEIG, we have started applying Kanban to a number of our internal services including sales, logistics, IT, delivery and marketing. Our marketing still isn't perfectly Kanbanized... although we have set WIP limits and a few policies, we are still missing many of the more advanced techniques that can be applied to improve the way we work.... and that's okay, as long as we continue to improve.

I want to recommend the Kanban System Design training to all my former students and Scrum-ish colleagues. It's an important domain of knowledge that you can apply to many work environments, and ultimately is compatible with Scrum. I've seen Scrum done very well, and I've seen it done very poorly. Learning about Kanban will actually help you do Scrum better, and get better business results.

Similarities Between Scrum and Kanban

Both Kanban and Scrum are about handling complex knowledge work. As such there are many similarities at a deep fundamental level. Both encourage the use of cadences (iterations) to implement various types of inspection and improvement. Both encourage the creation of visibility of the work to make it more manageable. Both encourage leadership among the people doing the work and responsible for the work results. Both encourage limiting the amount of work in progress. Both can be applied to almost any scale of effort from a few people to thousands of people. Both can be applied to work on a short timescale or a long timescale. And ultimately, both have the same purpose: to make work better for both those doing the work and those who need the work done. Both lead to real agility.

What are some of the differences? What ways do they give different advice?

Difference 1: Applicability

One of the fundamental differences between Scrum and Kanban is the notion of what kinds of work they are ideally applied to: Scrum is for Product work, Kanban is for Service delivery. Realistically, of all the work out there, much more work is service-oriented. IT work is almost completely service-oriented. The core of most companies is to provide a service. Scrum is extremely popular, for good reason, but more and more it is being mis-applied... it's a bit like using a hammer to pound a screw into wood. Not every problem is a product development problem! Using the right tool for the job is an important part of becoming a mature organization.

Difference 2: Ease of Adoption

However, in my experience, the most important difference is related to how Kanban is gentle, and Scrum is harsh. Ron Jeffries has described something called "Dark Scrum". Dark Scrum is extremely common in part because of how difficult it is to do Scrum properly. In my experience as a consultant and trainer, 90% of the Scrum out there is Dark Scrum. There's also "proto-Scrum" and "ideal Scrum", in approximate proportions of 9.9% and 0.1% respectively.

Shades of Scrum

Ideal Scrum: follows all the explicit rules, principles and values as defined in the Scrum Guide, adds things to the framework that are compatible with those rules, principles and values, and is applied to the correct types of work.

Proto Scrum: doesn't follow all the rules, principles and values, but... both the intention is good and the application is good. In other words, the team and the organization want to do Scrum properly and they are using Scrum for the right kinds of work.

Dark Scrum: (experienced as human misery) no intention to follow the rules, principles and values, and no intention to use Scrum for the right kinds of work. Often this is just about doing the same old bureaucratic shit, but faster.

FWIW, the path from Proto Scrum to Ideal Scrum is mostly about the maturity of the organization in supporting true cross-functional teams. There are other aspects as well, but this is often the main driver of Scrum maturity.

Shades of Kanban

I don't know from personal experience if something like "Dark Kanban" exists except to say that we have helped a small number of organizations (3) who were failing with Kanban to apply Scrum successfully... but this is rare. But certainly proto-Kanban is common. This is Kanban applied at the level of a single-function team (e.g. a development team) rather than at the service level. What is interesting is that for Scrum, a single-function team is usually "Dark" whereas for Kanban, a single-function team is merely "Proto".

What I did learn from my Kanban System Design class is that there is no end-state ideal for Kanban, but that there is a very very very small core of ideas and practices that constitute the starting point where you can say "we're now doing Kanban". For details, please check out the Kanban Maturity Model.

One of the core ideas in Kanban is to start with where you are. This is significantly different from Scrum which requires a significant set of changes to get started. Therefore, the motivation for change matters: if you are looking for incremental or evolutionary improvement, Kanban is going to be more appropriate... and if you are looking for dramatic or revolutionary improvement, Scrum is going to be more appropriate.

Difference 3: Kanban Method vs. Scrum Framework

Angels dancing on the head of a pin. 'Nuff said.

Difference 4: What About Management?

Kanban is positioned as a management method, and often the people promoting Kanban cite this as a differentiator to Scrum. While there is some (very old) historical truth to Scrum being for software development teams, it has been at least 20 years since that has been the exclusive domain of Scrum. Based on both practice and theory, Scrum is also fully a management method. As an example, I have seen Scrum used successfully by management teams where the "product" under development is the organization itself.

This is a difference without a difference.

Difference 5: Kanban is Not Agile, Scrum is Agile

This is a tricky one. It depends a lot on how we define "Agile" (or "agile"). Martin, an expert on Kanban that I greatly respect and I had a brief conversation about this topic. Basically, there are a few ways to frame this (potential) difference:

1. Historical roots: Neither Kanban nor Scrum are "Agile" by this definition. Both Kanban and Scrum are actually rooted in Lean thinking.
2. The Manifesto for Agile Software Development: Again, neither Kanban nor Scrum are "Agile" by this definition. In part, this is obvious from the fact that both are used frequently for non-software types of work.
3. The characteristic of "agility": Here, both approaches often help organizations increase their agility (their ability to respond to changing customer needs and competitive market forces). And, for both approaches, agility is not the only thing that they "care about".
4. The colloquial use of the word "Agile": Here, both approaches are de facto Agile methods. Almost everyone who uses the term Agile without precision (those who have not been deeply educated on the history and methods in question), will naturally classify Kanban and Scrum as Agile methods, largely due to the incredible amount of similarity between the two approaches.

Again, a difference without a difference. The only tricky bit here is when people are using terminology in different ways without being clear they are doing so. A Kanban expert talking to a non-expert marketing person may wax pedantic about how Kanban is not an Agile method, while the marketing person won't care a fig because the people they're trying to attract have just heard the Agile buzz-word.

Conclusion

I'm not a Kanban expert in that I am not an Accredited Kanban Trainer, nor am I a Kanban Coaching Professional. I'm not even a Kanban Management Professional. As such, there may be important similarities or differences that I am missing. However, I am a recognized Scrum expert. I strongly believe that Scrum practitioners should learn about Kanban and the Kanban System Design course is a good starting place. You will see many similarities and a few differences... and you will learn that Scrum and Kanban are complimentary approaches to working.

My colleagues at BERTEIG have some courses coming up and I encourage you to register:

Ottawa, April 24-25 - Kanban System Design with James Steele

Toronto, May 15-16 - Kanban System Design with Travis Birch and Jerry Doucett

Toronto, July 4-5 - Kanban System Design with Travis Birch and Jerry Doucett

* STATIK: Systems Thinking Approach To Implementing Kanban