Episode Transcript
Scrum versus Kanban; what's really the difference? Which is better? Should our struggling Scrum team switch? We get questions like this from clients and students all the time. So in this episode, I'm going to break down the key differences between Scrum and Kanban. I'll share what I think are the strengths, weaknesses, and sweet spots for each, and we will look at why they actually work together really nicely in different situations and how Scrum versus Kanban is actually the wrong framing.
I'm not going to get into how to implement Scrum or how to set up a Kanban system. We talk about those things elsewhere and we'll share links in the show notes on our website. This episode is about how to think clearly about each approach so that you can use the right tool or combination of tools for your situation.
First off, let's get clear on the difference between the two approaches. The single biggest difference between Scrum and Kanban is this: in Scrum, you limit how much work you need to focus on at once using a time box. That's the sprint, the one to four week cycle where you plan and focus, and then reflect on what you did, think about how to improve, and do it over and over again.
In Kanban, by contrast, there are no time boxes. You focus your work by using Work In Progress or WIP limits. You may decide, say, your team is only gonna work on two or three things at at a time.
There are a bunch of other nuances, like what meetings you have, what you call things, the states that work goes through, the policies around work. But mostly it comes down to time boxes or WIP limits as your main tool for focus.
When a team is using Scrum well, it's a nice container for collaboration and continuous improvement on small, valuable work items. We talk about this more in our Why Scrum Works When It Works episode, and we have a ton of advice about the different parts of Scrum on our Good Scrum landing page.
When a team is using Kanban well, they get visibility into how work flows through their system so they can make it flow better. They can reduce cycle time and increase throughput. That focus on making work flow smoothly is really valuable because most organizations have tons and tons of unfinished work hanging around for various reasons.
So when should you use each one? Well, we like Scrum as the starting point. If you're doing plannable work like software development, time boxes just fit nicely with how humans naturally function. We naturally plan and reflect in years, quarters, months, weeks, and days. It's how our bodies and minds work.
We like Kanban for work that's not so plannable like operations and support.
We've certainly seen examples of product development teams using Kanban to good effect, and we've seen examples of operational teams using something like Scrum to structure their ongoing and project work, if not the responsive part of their work. But in general, as a starting point, if you're doing plannable work, start with Scrum. If you're doing emergent and responsive work, start with Kanban.
Diehard Kanban advocates will say that one of the advantages of Kanban is that you start where you are. You visualize and incrementally improve your current system, so it's easier from a change management perspective, it's less disruptive.
Now I get that point, and I've even occasionally suggested Kanban for this reason in cases where gentle incremental improvement was the right thing. But in my experience, helping lots of organizations over the years, most people who reach out to Humanizing Work would benefit from the disruption of forming a real cross-functional team and putting some minimal structure around their work. So Scrum introduced with care can actually be a better place to start despite some potential short-term pain.
Now, up to this point, we've been distinguishing Scrum and Kanban and talking like you're just gonna choose one or the other. But the reality on most successful teams is actually a combination of both. You pick either time boxes or WIP limits as your primary organizing tool, and then you borrow elements from Scrum and Kanban to solve specific problems.
It's kinda like this. Which is better for managing your personal work, a calendar or a to-do list? For most people, the answer is both, but it'll lean one way or the other. One will be the primary tool and the other will fill in gaps. For example, if you're a doctor seeing patients all day, your primary tool for organizing work is your calendar, and then your to-do list will catch things that don't happen during appointments, like reading an article in a medical journal, or completing admin tasks.
If you're a freelance writer, most of your work is going to be shaped by your to-do list. Your pieces have deadlines of course, but you mostly have freedom when you work on them each day. The calendar will capture appointments that you need to work around, but it's not the main tool.
If you're a college student, it's a more even mix. Your classes land on the calendar, but your assignments and your studying are organized by the to-do list.
So along those lines, let's look at a few ways that teams benefit from adding a little Scrum to their Kanban or a little Kanban to their Scrum. The first of these is Scrum-like events in a Kanban system.
The four Scrum events do a minimal set of jobs that most teams need. Sprint Planning answers what should we focus on next? The Daily Scrum answers how should we work together today to get the most important work done? The Sprint Review speaks to, are we going in the right direction? Are we making progress like we expected in the sprint? A Retrospective gets a team to align around what experiment they wanna do to become more effective at their work.
Many common teams benefit from something like those four events, but since there's no Sprint, they don't have to happen on the same cadence. You might examine and refine your input queue of planned work every week. You might demo and reflect on the results every two weeks. You could have a retrospective once a month.
It's kind of funny. We've noticed that teams who leave Scrum for Kanban because they complain that Scrum has too many meetings, but then who take continuous improvement seriously, they inevitably end up with their own versions of the four Scrum events just with different names.
Okay. The second way that we've seen teams benefit from combining Scrum and Kanban is with our PO Board backlog model. It's a Kanban system for the Scrum Product Backlog. Work flows from ideas on the left to completed work in production on the right. We limit Work In Progress in the backlog at different levels of detail, so backlog refinement emerges just the right information just in time. You can learn more about that in our PO Board episode, which we'll link to in the show notes.
So that was Kanban sort of around Scrum. The next combination is adding some Kanban within Scrum with what we call an expedite lane. In Scrum, there's just one of what Kanban would call a class of service, a type of work item that gets a certain policy applied to it. Namely it's plan something in sprint planning, and you can expect it to be done by the sprint review. That's the standard class of service. Need something mid sprint? Well put it on the backlog for the next sprint. But if a Scrum team does both new development and production support, they can find themselves with genuine emergencies that can't wait until the next sprint, like a production system is down.
You can't really go to your stakeholders and say, sorry, we'll get to it in a couple weeks. So adding another class of service provides a structured way to handle emergencies without breaking the focus in the time box that makes Scrum so useful. You can learn more in our episode about dealing with interruptions on a Scrum team.
The fourth combination that we like is using WIP limits from Kanban to solve a common Scrum team dysfunction. Many Scrum teams fall into the trap of working on a bunch of different things in parallel. Some even structure their work so that they don't have to collaborate on the same work items. And this undermines a lot of the benefits of Scrum.
So if you wanna change that, one way to work towards making a change there is to borrow the WIP limit idea from Kanban. As a team, you could agree to run an experiment for a few sprints where you're only gonna work on say two or three items at once, even if it feels slower. And that naturally forces people to collaborate more, and a lot of times, figure out how to collaborate if they've never really worked together on the same items before.
This also helps avoid the, develop a bunch of stuff and throw it over to the wall to testers inside of Scrum. With a WIP limit, you can't start developing more things until the ones you just developed get tested. So I've seen that push teams towards, a practice, like Behavior Driven Development. It's a positive pressure towards bringing the tests forward. When you realize that piling up work for testing doesn't actually help you get more done, it makes sense to move the testing effort to the front and make it more collaborative. I wrote a whole book about that, Behavior Driven Development with Cucumber, and we'll link to that in the show notes too.
Finally, it's worth mentioning a common pitfall that we've seen when it comes to Scrum and Kanban teams struggling to deliver, say something like, "Scrum doesn't work for us. Let's switch to Kanban," and then the quote Kanban that they switch to has no WIP limits, no cycle time tracking, no experiments to improve flow. They're not really trying Kanban, they just gave up the constraints of Scrum.
So if the constraints of Scrum are making it apparent that you're not delivering, don't just remove those constraints and call it Kanban. Identify and remove the root causes for your delivery issues. And adding elements of real Kanban within or around Scrum can actually help, like a tight WIP limit can make it really visible where work gets stuck in a sprint.
So to recap, the biggest difference between Scrum and Kanban is their mechanisms for creating focus on a team. Scrum uses time boxes, Kanban uses WIP limits. There are other differences, but that's the big one. We recommend starting with Scrum if you're working on plannable work, like building a product. Start with Kanban when you're doing responsive work like operations or support. Whichever one you choose as your primary tool, you can borrow elements from the other to make things work better, such as Scrum-like events in your Kanban system, Kanban around Scrum with our PO board backlog model, and expedite class of service to handle emergencies within a sprint, and WIP limits to help your Scrum team collaborate more and reduce cycle time.
We'd love to hear what other Kanban and Scrum combinations you've found useful. Share in the comments on YouTube or LinkedIn. And if you found this useful, would you do us a favor and take a second to hit the like button on this episode on YouTube? It's really encouraging to us and it helps other people find resources like this that we put out there. And visit humanizingwork.com to schedule a free consultation if you're interested in our help getting the right combination of Scrum and Kanban for your team. Thanks for tuning in to the Humanizing Work Show, and we'll see you next time.
