Kanban solves our failed Scrum implementations, right?
“Scrum is lightweight, simple to understand, but difficult to master.” — The Scrum Guide
Kanban is often the go-to solution when Scrum implementations are failing. But is it that simple to switch between the two? Why is Kanban often seen as the savior of demoralized and dismantled Scrum teams?
Failing with Scrum
The most common thing you hear when teams, organizations, and companies fail with Scrum is:
“Yeah, well, Scrum didn’t really suit us.”
The compulsory followup phrase to that statement is:
“So, we switched to Kanban!”
I can understand them, sometimes it can be easier to start with Kanban than with Scrum. It, of course, all depends on your context and ability to adapt to change. But always remember, Scrum is easy to learn but hard to master. The same thing goes for Kanban.
“Help us, Taiichi Ohno. You’re our only hope.”
A simple explanation of the difference between Scrum and Kanban is that Scrum can be seen as a revolution. This revolution often contains radical changes in roles, events, and a significant difference in mindsets about how to build digital products. All of this implemented and changed at the same time, sometimes even overnight. It can really rock your boat if you’re not sitting down comfortably with your lifejackets on.
Kanban is more of an evolution of your current situation that you step by step improve. Changes become smaller and more manageable this way. Roles may change, but it might not change your working environment as drastically as an implementation of Scrum. This evolution, however, doesn’t necessarily mean that you have to ditch Scrum altogether.
You’ve probably spent a lot of time and money building your Scrum team. Try first to utilize Kanban’s idea about reducing waste. Waste can take on many forms, and maybe some activities that make you fail with Scrum can be identified and removed before you make any other changes.
But what is it with Kanban that teams think is so much easier than with Scrum? In some cases, implementing Kanban can be even harder to do than implementing Scrum. When the switch from Scrum to Kanban is on your team’s agenda, there are a few common pitfalls that I want to address.
First, a short introduction to Kanban
Kanban is a visual system for managing work as it moves through a process. A Kanban system visualizes both the process (the workflow) and the actual work passing through that process.
The goal of Kanban is to identify potential bottlenecks in your process and fix them so work can flow through it cost-effectively at optimal speed or throughput.
With Kanban, you’ll be able to see all the good, but also all the bad things that you probably haven’t seen before. When bad things in your process are visualized, you need to be able to act on what you see. If not, you’re risking implementing faux Kanban.
Faux Kanban
When I coach teams to work with Kanban, it’s in the majority of the cases because the team themselves wants to do it. They might have failed with Scrum and gotten buy-in from management to try Kanban. This differs from a Scrum implementation. Scrum is, in some cases, required by teams to use because a lot of organizations and companies see Scrum as the definition of being agile.
If a team wants to use Kanban instead of Scrum, they ought to be motivated to change their behaviors and ways of working to make full use of it. But the illusion that Kanban will automatically give your team, company, or organization an innovative start-up feeling the first day you try it, is a fallacy.
The pitfalls of faux Kanban
No working agreements
The first two things you should ask yourselves when you’re changing the way you work is “why?” and “how?”. I talk a lot to teams about the importance of creating working agreements, team agreements, code of conduct, contracts, or whatever you like to call it. It’s vital to have guidelines on how you are going to collaborate and communicate in your team.
“Can’t we just start coding?”
A switch from Scrum to Kanban means that you reset the team. When you reset the team, you’ll need to form new agreements. By not creating any agreements on how to work with Kanban, you’re taking your first steps to implement faux Kanban.
It would be best if you talked about how you are going to form your Kanban system. How can we limit work in progress? How do we replenish our value stream? How do we solve bottlenecks? What policies will we incorporate? By agreeing to things like this, you have a foundation for a successful Kanban system.
No visualization
A Kanban system should visualize your whole process. This is easiest done by the columns “to do,” “doing,” and “done.” To make work flow through your process, you’ll need to break down work to small batches. This is because fewer states in your process require smaller batch sizes to be effective. In other words, “to do,” “doing,” and “done” should give you enough visibility into the flow.
“If you can’t see it, you can’t improve it.”
If work is too big, you’ll be required to visualize more states to make it clear where in the value stream your large batches of work are located. This will inevitably slow down your flow and create bottlenecks. By breaking down work, you make it easier to visualize how an idea can make it through your process all the way to production as fast as possible.
No WIP limits and no flow
If we are using Kanban, we are utilizing the power of flow. This ought to mean that the more work we start, the more work will flow through our process, right? Not really.
“Test is blocked, so I’ll just pick up a new item from the backlog.”
When bottlenecks are created, the go-to solution for faux Kanban teams is to start new work, which makes it even harder to create flow. The more work you start, the more likely it is to slow down and get stuck in your process. “Stop Starting and Start Finishing” is not on the agenda in faux Kanban teams.
An experienced team that works successfully with Kanban handles this differently. As soon as something is blocked, everyone drops what they are doing and swarms around the bottleneck. Their highest priority is keeping flow by removing the bottleneck together as fast as possible.
No pull, or not being able to say “no.”
If you’re not using WIP limits, you’re most likely not taking advantage of the “pull system.” A pull system is a technique that is used to control the flow of work by only replacing what has been consumed. This means that the trigger for work to be done is when there is a demand for it. This differs from a push system where work is being done just in case there is a demand.
“I know you’re at full capacity, but I thought you worked with Kanban? So go ahead and start working on this anyway.”
With a pull system, we are given a tool that helps us to say: “no, we cant start new work until we can do so.” This helps us to manage product owners and stakeholders who might think that just because we’re not working in sprints, it doesn’t mean that you can work on everything at the same time.
No proactivity
A misconception I encounter when teams are struggling with Kanban is that they think that meetings and planning don’t exist in Kanban. That it is some magic tool that does all that for you without any effort. Of course, that isn’t the case. When the work that flows through your team’s value stream starts to diminish, you’ll need to replenish with new work to make the flow continuous.
“But we don’t need to plan, we are using Kanban!”
With Kanban comes great tools like measuring throughput to forecast how much work a team can complete during a specified period. If your team completes an average of ten product backlog items per week, you’ll have valuable data to use when making forecasts on the product backlog to help with making forecasts and replenishing your value stream.
No continuous improvement
When you lose the guidelines from Scrum, events such as the sprint retrospective meeting is often the first to bite the dust. Mainly because retrospectives are so connected to the Scrum framework that teams think you don’t have to inspect and adapt your processes when working with Kanban.
“We are working with Kanban, not Scrum. Retrospectives aren’t for us.”
Even if we succeed in forming working agreements, visualize our processes, replenish our value stream on a steady cadence with a constant flow, we still will need to identify improvement areas and take actions.
By bringing some of the valuable events like the sprint retrospectives into our Kanban system, we will have a tool to help us to focus on identifying and talking about improving our process. If there is one thing you always should use, no matter if you use Scrum or Kanban, it is the retrospective meeting.
When all else fails: take a deep breath
If you fail with Scrum and you fail with Kanban, what can you do? As many Agile coaches and Scrum masters will tell you:
It depends, every team, company, organization, and context are unique.
Try to identify what’s working, what’s not, and what needs to be changed to succeed.
How to experiment with Kanban in three simple steps
I’ve created three steps to help teams to develop the right prerequisites for working successfully with Kanban; “Agree-Form-Action:”
- Agree on how to collaborate and communicate.
- Form and visualize your process.
- Take action and start experimenting.
If you struggle with Scrum, experiment if Kanban is something that can help you. Use these three steps as guidelines, and identify along the way what’s working for you and what’s not.
One final important advice
Did you really put all your effort into your Scrum implementation? Honestly? Make sure you discuss this in your team before talking about switching to Kanban. No one likes a quitter.
“It’s a dangerous business, Frodo, going out your door. You step onto the road, and if you don’t keep your feet, there’s no knowing where you might be swept off to.” ― J.R.R. Tolkien, The Lord of the Rings
Thanks to Scott Weiner for early review and feedback, and thanks to the Serious Scrum community for feedback and improvement suggestions.
