Scrum and Kanban, What’s the difference?
My intention was a short blog, but it quickly grew into a long one to explain what I meant. With that in mind, the conclusion is at the top, please read that first, then decide if you want to go on to read the “working out” in the Body.
- Both Scrum and Kanban are good things but are very different beasts.
- Kanban is a way of getting better at doing what you do.
- Scrum is a way of being agile in software delivery.
- Scrum is more than just a framework, its essence is really its Values and Ethos: Inspect and Adapt.
- The Scrum Framework is really just a “starter for 10” to get you started in agile development.
- Many people think the Scrum Framework = Scrum, but this is incorrect.
- Kanban is not a methodology or framework. It is a way of evolving and continuously improving your framework.
- Kanban doesn’t have a suggested framework, it challenges you to start with what you do now and improve.
- Comparing the Scrum Framework and Kanban is like comparing apples with fruit.
- It’s still a useful comparison if only so that we can explain the difference, and why you can use Kanban to improve on pretty much any way of working.
- When you’re trying to evolve and improve, everything is up for grabs.
- Evolving from a pure Scrum Framework to a Kanban implementation is easy, and you can still call it Scrum
Still with me - thanks. Lets get into it.
As an Agile Coach / Trainer and Kanban Coach / Trainer I’m often asked what the difference is between Scrum and Kanban as if we are comparing two different Methodologies. This is a much more difficult question as we have to address some misconceptions before we can answer in a meaningful way.
What is Scrum anyway?
Scrum is NOT a framework for software delivery. (If you think this is contentious, bear with me a little).
The Scrum Framework IS a software delivery framework, but while that sounds like splitting hairs, it really isn’t and if you are stuck in the “Scrum is the framework and that is all Scrum is” way of thinking you are imposing a false limitation on the way you are working.
Scrum > Scrum Framework
So I ask again, what is Scrum?
Scrum is an agile way of working which includes Values, an Ethos and a Framework for software delivery. The framework is the easy bit to learn, teach, test, and write about, so it is the part of Scrum that tends to get the focus. It is also the lightest weight part of Scrum once you get into the other areas.
Agile at it’s roots is really a set of 12 principles listed here http://agilemanifesto.org/principles.html The Scrum Values: Focus; Commitment; Openness; Respect; and Courage, are really focused on addressing the 12 principles of agile. They tell us what Scrum is really about, it’s about working together effectively and transparently as a team, being brave in our approach to our work and way of working.
The ethos of Scrum as I see it is really: 'Inspect and Adapt’; and be Agile.
So what about the Scrum Framework?
The Framework is the easy bit. Here’s a set of rules: roles; practices; and meetings. If you follow this set of rules, things should improve and you will find you are starting to become more agile*.
One Sprint into Scrum, you should have your first retrospective and start getting down to the Inspection and Adapting. Here comes the problem. If you are committed to the Scrum Framework as being sacrosanct, then you are limited in what you can adapt. We have surely all heard of ScrumBut as a concept (we do Scrum, but we don’t do xxx) which is presented as an anti-pattern. To most of us this really means we do the "Scrum Framework, but we don’t do xxx”. But how can we truly be agile and commit to inspect and adapt if you choose to constrain ourselves to never changing large parts of how we do our work? I think Scrumbut as a concept does more harm than good.
In that situation you either have to live with Cognitive Dissonance or you have to accept that the framework is just a "starter for 10” to get you started while you get to understand the values and ethos, and start becoming more agile.
That’s how I treat the Scrum Framework. It’s a good place to start, but since your particular context was never considered in the creation of the Scrum Framework, it may have worked perfectly “there and then” it cannot be perfect “here and now” in this different context. If you are developing software, then there is a good chance it will be good enough to be a lot better than a non-agile way of working, which is why it makes a good starting point for new dev teams just being formed for the first time, or for people who choose to make the revolutionary change from waterfall to agile**.
I am sure that the creators of Scrum never intended any part of it to hold you back from improved agility or higher performance. If you find that something inside the Scrum Framework is holding you back, you have the right and the responsibility to inspect and adapt. I would argue that evolving your framework from the ‘vanilla’ Scrum Framework is more Scrum than sticking to the Scrum Framework rules dogmatically.
What is Kanban
If you already know the answer to that question, keep reading, more than 90% people I’ve met who 'know this already' tend to get it wrong.
Kanban is a descriptive method for evolutionary change based on the use of simulated kanban systems.
Yes Dan, but what does that actually mean?
The first thing it means is that Kanban is not a methodology or a framework. That is important.
Comparing Kanban to the Scrum Framework is unlike comparing apples with apples or even apples to oranges, instead it is more like comparing apples to fruit. That is why it is such a hard question to answer.
“What's the difference between a Ford Fiesta and Volkswagen Golf" is easy. "What’s the difference between a Ford Fiesta and a vehicle” is harder to answer because you have to interpret the question and change it before you are able to answer.
Kanban doesn’t tell you how to do software delivery (or any other knowledge work). It tells you how to get better at software delivery (knowledge work). Every implementation of Kanban can (and should) be different. Some can even look a lot like Scrum on the surface. Others look nothing like Scrum. The key point is that Kanban allows teams to continue making small improvements and changing to what is needed as the context they work in changes.
The foundational principles of Kanban are: start with what you do now; agree to pursue evolutionary change; initially, respect current roles, responsibilities & job titles. That means Kanban is applied over your current way of working, and you then start making improvements. There is no target perfect framework, only the concept of getting better at what you need to do. If you do Scrum today, when you start your Kanban journey, you do scrum tomorrow, but then you change your process to what you need it to be, no matter what a book says. At some point soon you will realise you no longer conform to the Scrum Framework. That is fine for both Kanban and Scrum.
Evolving from the ‘Starter for 10’ Scrum Framework
It doesn’t take a lot of mental work to allow that a Scrum Framework is close enough to call an implementation of Kanban. Good Scrum conforms to the core practices of Kanban. Once a good Scrum team has got going (at some time after an agile transformation) it conforms to the foundation principles of Kanban. The only thing you have to do is release yourself from the shackles of ‘sacred rules', allow yourself to improve by collaborative experimentation, and implement a reasonable measure of productivity*** so that you can validate your learning and demonstrate your improvements. Everything is up for grabs
Look at your rules, work out if any of them are holding you back, actively decide to break (change) the first rule that is slowing you down, and measure if it made things better or not. Move onto the second rule change. Keep on doing that. Feedback -> change -> measure -> feedback…. This is Inspect and Adapt, or Probe, sense, respond, or plan, do, check, act, or even scientific method.
The dirty little secret
You don’t even have to call it Kanban, if you prefer you can still call it Scrum, if you mean Scrum in the wider sense than just the Scrum Framework.
Want to learn more?
book yourself up for our Kickstart Kanban class here
* I’m a firm believer that agile is something you are (or become) rather than something you do.
** which is a risky business in itself and usually takes longer to show benefit than organisations predict. Hitting the road running with benefit is hard and rare.
*** try Lead Time: the real elapsed time between Committing to finish a Work Item and finishing that work item; and Delivery Rate: How many Work Items you finish per day.