Scrum Vs Kanban | Not What You Think
Most articles talk about differences in processes, roles, and artifacts between Scrum and Kanban. That’s not what this article is about. Those articles often give the impression that these two frameworks are interchangeable too. They are not; and I’ll talk about why that’s so important to understand.
Now, I’m not saying that one is better than the other. I love both of these frameworks and suggest using either or both when appropriate. While they are not interchangeable, they are not mutually exclusive.
This article is about the intention of each framework so that you can better identify when to use each and use them to better effect. There are three ways we can think about these differences.
#1
Scrum: Identifying and focusing on the most important things to do
vs
Kanban: Improving the quality of the things we do
Scrum’s framework is designed for consistent market feedback and adaptation based on that feedback. The product owner role is designed for improved customer collaboration and market understanding. Sprints are time-boxed with a focus on a working product at the end specifically so that the value of work can be verified with customers at regular intervals. Planning, daily scrums, and retrospectives are all opportunities to reflect on the value the team is intending to deliver – and provide opportunities to pivot based on new learnings about customer value. Every step of the process is meant to learn more about customer needs and adapt accordingly.
Interestingly, Scrum has some overlap with Kanban as well, where teams can collaborate with each other to improve internal processes, quality, and interpersonal dynamics. But this is secondary to value maximization.
Kanban is about improving product quality. Wait, isn’t it about improving speed through WIP limits, just-in-time, pull structures, Kaizen, and waste reduction?
Actually, no.
Sorry for the little tangent here, but it’s essential to address this common misperception. While all of these are core concepts of Kanban, which was popularized by Toyota, the intention was to build streamlined processes to identify and address any quality issues. This made their production system fragile, stopping production the moment a quality issue surfaced. At a time when the general rule was that production lines never stop, Toyota introduced the idea that anyone could and should stop the production line at the first sign of trouble. As we learned later, by focusing on quality upfront, the end result was better process efficiency and speed as well.
So, while Scrum is designed to learn externally about customer value and adapt accordingly, Kanban was designed to learn internally about quality issues and adapt accordingly.
#2
Scrum: Solving complex problems
vs
Kanban: Solving complicated problems
Everything from #1 still applies here, but it may be valuable to consider the differences between Scrum and Kanban by the type of problem you are trying to solve.
Complex problems are problems where we don’t really know what the solution is yet. To find the solution, we need to remember our grade school science classes and… experiment. In my experience, most problems we try to solve for customers are complex. Humans are influenced by many factors and biases, some of which can cause them to say they want one thing, but actually want something entirely different. Markets too are often volatile, uncertain, and ambiguous. The best plan is to assume your ideas are wrong and work to find the right ideas as quickly as possible. This is where Scrum shines.
Complicated problems have knowable causes and effects. We know, clearly, that if we produce the solution, it will solve the problem, and we don’t need to experiment. Notice that a complex problem can become a complicated problem after some learning! Since we know what needs to be built, the focus is on how we build it. This is particularly useful when we go through the same process many times since each improvement will have a multiplier effect. This is where Kanban shines.
#3
Scrum: Figuring out what thing to build
Vs
Kanban: Building the thing better
As I already covered, Scrum is a fantastic way for figuring out what a customer actually wants. This is done in two ways, by building and shipping a working product or service and then seeing how customers react, or by doing product discovery and running even shorter experiments using prototypes or validation techniques to create internal value through rapid learning. Of course, when done well, Scrum teams will usually employ a mix of both.
Kanban assumes that you already have a solution that customers want, and you want to deliver that solution to customers better. This is done by improving quality, process efficiency, and automation. It is enormously important to make sure that the solution is actually validated before investing in these areas though, or they will be wasted efforts.
Kanban is often used by internal, operations teams where they offer software as a service for internal users. This means that business users will write out a specific, desired solution, and hand it off to the operations team. However, it may be useful to consider Scrum instead where those teams take responsibility for understanding and solving the underlying problems in the company, rather than simply following whatever solutions the business offers them.
Conclusion
So, should your team use Scrum or Kanban? There is no right answer. It depends on what you are trying to achieve. It may make sense to focus on just one framework, change from one framework to another based on the problem you’re currently trying to solve, or mix the two together. Regardless, I hope you have a better understanding of not just how Scrum and Kanban are different but WHY they are different.
