Mike Lyons explains how Kanban differs from Scrum: it focuses on flow rather than sprints, came from manufacturing, and uses WIP limits to smooth work and expose bottlenecks. Kanban works better for interrupt-driven teams and support operations that can't commit to fixed sprints.
I want to pause our discussion around scrum. We've been doing a lot in the scrum 353 and that's all yummy goodness. But I want to talk about Kanban. Kanban is an entirely different discipline than scrum. Now, do the two sometimes get combined and used together? Absolutely. Are they based on lean principles? Of course. Do they fall within the Agile umbrella of software delivery and value delivery? You bet. But Kanban teams are really focused on different things than SCRUM teams. So we know so far that Scrum teams are focused on the time box and delivering to short, iterative commitments from a prioritized list of work. And they manage change through that time box and they commit to stories and story points and they measure velocity, things like that. Kanban teams are focused more on flow and the flow of work. They don't so much care about the time box. They don't run in sprints, they don't have a Scrum master that. They're not using the SCRUM practices as we've been talking about. They're focused on different delivery methods. Their metrics are different. Different. The way the teams behave are different. Kanban originated long before any sort of software development practices were coming about. It comes from the manufacturing industry. And Kanban literally means sign or signal board. Sometimes it's the idea that on a Kanban board, the open slot is the Kanban. It's a signal that there's an opening for work to move into that process. Additionally, Kanban sort of we say we start where you're at. We map out all of the processes in your workflow. What comes first? What comes next? What do you do? Third, Kanban doesn't attempt to change any of that. No, what we attempt to do is make that visible and bring that work into clarity. Those are the columns in your Kanban board. Then we apply WIP limits. So in our example, we've got a WIP limit of four in development, we've got a WIP limit of three in testing and a WIP limit of six in deploying. Those WIP limits help to smooth out the flow on our Kanban board. By displaying these process columns on the Kanban board, we begin to reveal hidden work in progress as well. Say, for example, you're dependent on a UX designer or a database administrator or some sort of security team. Maybe it's a review process, something outside of your team. Well, the Kanban board will reveal that because the card will be stuck in a particular process, while we're dependent on the other team to Give us whatever they're working on, give it back. Visualizing that on the board brings that quickly to our attention. When we begin to see cards sort of stacking up in the testing column, we can begin to ask sort of why is that? What's causing the backup on the highway? WIP limits also help us increase the cross functionality of our teams. Say for example, development. They've met the WIP limit there. The developers now can't pull in a new story on our team and the testers on our team, they start to move things out to deployment. So there's an opening in testing. Well, that development card can move over to testing. When that happens, what happens if they're both full, they're both at their WIP limit. A developer can't pull a new story in, but the developer might be able to go help the tester move a story over to deployment. So developers, yeah, you can actually go do testing. Maybe you don't test your exact same story you wrote, but maybe you could test another person's story. We're all learning and growing and becoming that cross functional team. Wiplimits help us do that. The Kanban board itself, that big view of our work, is what helps us see the bottlenecks in the system. This all ties back to something called the theory of constraints. And while I don't go too deep into that in this class, keep in mind the theory of constraints is that we want to identify our constraints in the system. And there's a classic quote that says any improvement in any part of your system other than the constraint is a waste of time. So focus our efforts on finding that constraint and eliminating it. Maybe it's a handoff, maybe it's training, maybe more people are needed to learn a skill set on the team. Whatever that constraint is, the Kanban board will help reveal that it's a common mistake on agile teams to think that there's sort of one answer to every team and it's, it's Scrum. Scrum is great and it works great on teams, but it may not work for every team. Perhaps Kanban is a better fit. Those teams that are regularly interrupted, that can't commit to a time box, that have high priority work pop into their queue at any given moment, think you're sort of operations and support, maybe service desk type work where you just never know what's going to break tonight. Kanban and focusing on flow allows us to do that.
