The potential and pitfalls of Scrum and Kanban
An oxpecker is a bird living in sub-Saharan Africa. They feed themselves with ticks and other bugs which they graze from the bodies of large animals. Oxpeckers have been a prime example of mutualism, where two species enjoy a net benefit from being together. The oxpecker gets its food, the host animal is being freed from pesky parasites.
Many see Kanban as an oxpecker for Scrum teams. Kanban and Scrum seem to be made for each other. But it’s not that simple.
In this article, I’m going to discuss the potential perils of using Kanban with Scrum. While doing so, I will also reveal an unexpected unfavourable trait of the oxpecker.
Is Kanban an oxpecker for Scrum? It’s not that simple!
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Faaaf8f27-ac99-4209-8643-26b68b4564bb_800x422.png)
Kanban and optimizing value
Kanban is all about optimizing the flow of value through the process:
“Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system.” — Kanban Guide
Value is a magic word in Scrum too:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” — Scrum Guide 2020
At first glance, Kanban and Scrum both appear to be fixed on value. Scrum has a value feedback loop. This feedback loop is the Sprint. Teams build product Increments of potential value and verify their assumptions through stakeholder feedback and measurements.
Scrum also has a second improvement cycle. At the end of every Sprint, the team inspects itself and aims to improve its quality and effectiveness. This is where Kanban can help Scrum Teams greatly.
The benefits of Kanban for Scrum Teams
Kanban focuses on the following measures at a minimum:
Work In Progress (WIP): The number of items in progress (which can be every status between starting and finishing an item).
Throughput: The number of items finished per certain period. For Scrum Teams, this period could be a Sprint.
Work Item Age: The amount of time an item is in progress.
Cycle Time: The amount of time from starting the item to finishing the item.
All of this exists to find the right balance in effectiveness, efficiency, and predictability. Scrum Teams that wish to improve on these areas can benefit from adopting Kanban. Here are a few examples of issues that could be addressed:
Overcommitting by planning more items than teams can finish in a Sprint.
Working on too many items at the same time.
Inability to finish items before the end of the Sprint.
Teams that struggle with their flow struggle to create value. Kanban helps to inspect and adapt to optimize your way of creating things. Teams measure their own performance data to learn how they could improve. With Kanban, teams can grow to be high-performing.
Optimizing flow doesn’t equal maximizing output
Kanban is about effectiveness, efficiency, and predictability. It is based on the assumption that flow brings value. This makes all the sense looking at the origins of Kanban: the automotive industry.
Taiichi Ohno developed Kanban for Toyota to optimize the flow of building the right things on the production line, using a pull system. For this industry, it is clear upfront how the plant should build the car right so that it can bring value.
The people from the plant will not do a re-design based upon direct user feedback of a car coming from the plant. This is not the concern of the manufacturing plant. They need to ensure they build it right. The cars coming from the plant are largely the same as all the other cars that were produced that same day, that month, or that year.
By contrast, software teams need to inspect if their working software is adding value. This is the reason why Scrum exists. Scrum helps to verify your assumptions that the outcome of your work brings you where you want to be. It exists to change directions to pursue your goals.
Kanban pitfalls
I discussed how Kanban helps Scrum Teams to optimize their effectiveness, efficiency, and predictability. Kanban operates from the assumption that what you’re doing is valuable.
Scrum Teams that have the value feedback loop firmly established will benefit from Kanban for this too. But for teams that struggle to inspect and adapt on value, this can lead to unwanted team behaviour, like:
Too much emphasis on effectively producing software, ignoring the factor complexity. Teams treat software creation as adding the doors to a car. They don't factor in that creating software products is a discovery.
Too much emphasis on the performance feedback loop, ignoring the value feedback loop. In doing so, teams may be tempted to consider the value feedback loop as waste. They could be tempted to remove the Sprint Review or turn it into a frivolous event.
Considering the delivery of all planned items as the purpose of the Sprint instead of meeting the Sprint Goal. An emphasis on flow may move the team away from what they wish to achieve, to what items they wish to create. Scrum is about creating value by achieving your goals.
Considering the Sprint Backlog as immutable to avoid a negative impact on the flow. However, a team should be flexible to adapt if they find better ways to meet their Sprint Goal.
Comparing software Scrum Teams with manufacturing plants. Building software and building cars are not the same things. What works for manufacturing cars doesn’t automatically work for Scrum Teams with complex work. The work of a Scrum Team may be too complex for Kanban to be helpful for them.
Many Scrum Teams already have a hard time focusing on the outcome, looking at output instead. To make matters worse, many organisations that work with Scrum Teams haven’t grasped the concept of setting goals at all.
Introducing Kanban to Scrum Teams in these positions can have a great positive impact. But if these teams don’t also embrace the value feedback loop, they can lead to more unwanted behaviour feature factory behaviour.
Kanban as a potential parasite
For teams that struggle to focus on outcomes, Kanban can become an additional problem. Remember the oxpecker from the start of the article? Well, there’s more to these birds too.
Oxpeckers don’t only remove pesky bugs from the bodies of their hosts. They aren’t only doing good. They also do harm to host animals. They open their wounds and drink their blood.
These days, there’s a huge debate about Oxpeckers. Are these birds actually more harmful than beneficial for the host animal? Most animals clearly show they hate the presence of the oxpeckers. Many people now consider the oxpecker to be a parasite for their hosts. They are a burden to them, not a relief.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fb45395ab-d6c0-46c3-8416-301c5a6d49c8_800x402.png)
Kanban can be a parasite to Scrum Teams. Kanban doesn’t verify the value in itself. Kanban does fully focus on optimizing the flow of value. Scrum Teams may have major benefits from using Kanban to improve this flow of value.
But without verifying this flow of value, there’s no proof you actually delivered value. The main concern for Scrum Teams isn’t the flow of value. It’s verifying if the value is truly added and changing directing if there are better ways.
Do Scrum Teams need to optimize their flow of value to optimize their outcome? I wish to challenge this. More important than optimizing the flow of value is to optimize your feedback loop to be able to adapt quickly.
Kanban? Look before you leap!
Kanban seems to be ideal for Scrum Teams. But it is not this simple. Kanban exists to optimize the process to create output. The Kanban Guide discusses value a lot. But Kanban doesn’t verify on value, only on flow.
In contrast to Kanban, Scrum does verify value. It is Scrum at its core. Sure, Scrum Teams should also look into becoming more effective in their work. But they shouldn’t overdo this. The risk of emphasis on optimizing flow is creating a feature factory!
The risk of optimizing flow is creating a feature factory on output, ignoring outcome.
Yes, Scrum Teams are working on the most valuable items first. Better flow helps complete more of these items. In theory, more value should be created. But only if this is verified to be true.
I also know teams who wish to entirely move away from Scrum. They want to work with Kanban instead. This is a treacherous path. Kanban alone doesn’t help you to deliver verified value.
In complex environments, you need more than (minimum) Kanban alone. You need to have some way to verify your value assumptions to be able to change if required. If you don’t want it to be Scrum, that’s fine. Still, there should be something else instead.
Be mindful when you combine Kanban with Scrum. You will not automatically get the benefits you expect. For it to work, you need to have a firm understanding of both Kanban and Scrum. And you should have your focus on value. You should not focus on the delivery alone, you should cover the complete value feedback loop too.
Oxpeckers are helpful for their host animals when the hosts are healthy and fit. But they are a threat to hosts that are wounded. Kanban can be extremely helpful for Scrum Teams with a firm understanding of how complexity influences your approach to create value. Kanban can be harmful to wounded Scrum Teams that have their focus on output and delivery only.