Speaker 1: Scrum and Kanban are the two most popular Agile frameworks in use today. And because they're both Agile, they practice many of the same ideas. They both believe in responding to change rather than following a plan. They both believe in working software over comprehensive documentation. And they both believe in the continuous delivery of working software. But there is one big difference between Kanban and Scrum. And it revolves around how iterative development is done. In Scrum, you plan sprints. The product owner, Scrum master, and Agile developers look at the backlog of features to be developed and figure out how many features can be completed in a 2 or 3 week sprint. Then, the sprint begins. Features get developed, and once the 2 or 3 week sprint is done, the progress is reviewed and a retrospective is performed. Planning, sprints, reviews, and retrospectives are all key elements of the Scrum framework. Now, here's the big difference between Kanban and Scrum. Kanban doesn't do sprints, which means there's no sprint planning, there's no sprint reviews, and there's no sprint retrospectives. It's a huge difference. Instead, Kanban developers look at the product backlog and pick a feature to work on. That feature then moves from the backlog's to-do list into the list of work in progress. When a feature is done, it's then moved to the done list, and the developer then picks another feature to work on. This is why Kanban is often referred to as a flow-based, just-in-time development methodology. Feature development is not boxed into time-limited sprints. Feature development is continuous and ongoing. The most critical features are developed first, providing what's needed just in time for the client. To capture the work that's being done, the work that's been completed, and the work that needs to be completed, Kanban uses something called a Kanban board. It makes the process very visual. Most Scrum teams adopt some form of a Kanban board to help visualize their progress. They also typically use Kanban metrics, like cycle time and work item age, to measure their success. As you can see, Scrum and Kanban aren't mutually exclusive. The flow-based perspective of Kanban can actually complement the Scrum framework and its implementation. In fact, I had a chance to talk to David West, the CEO of Scrum.org, and here's what he said when I asked him about the difference between Scrum and Kanban.

Speaker 2: Wow, that's obviously a really political hot topic there, Darcy. So, I mean, ultimately, they are very complementary, and it's kind of disappointing that people consider them to be, you know, competing approaches or frameworks. You know, Kanban is all about visualizing work, actively managing the items in the workflow, you know, with things like WIP limits, et cetera, and generally continuously improving that workflow. Scrum is something slightly different. Scrum is about solving complex problems. It's about aligning teams on pursuit of those complex problems through a product goal, a sprint goal, a self-managed team working together to deliver against that, a backlog, et cetera. So I believe that the two can work in perfect parallel. One, probably the most important thing is to be effective in Scrum, you have to make things transparent. You know, in empiricism, it's the heart of Scrum. Kanban is a great mechanism for making the work transparent, you know, visualizing it through a Kanban board, et cetera. Obviously, another key element of Scrum is the daily Scrum, and the daily Scrum is about, you know, talking about how the work's going, making sure that the team is inspecting and adapting that work. So actively managing the workflow is a fundamental part of that, you know, and then continuous improvement is key to Scrum with the sprint review and the retrospective. The sprint review is about improving with feedback from stakeholders, the product and the outcomes that you're going to do next, and obviously the retrospective is very much focused on improving how you work. So improving the workflow is part of that. So it just seems like the Kanban and Scrum are designed to work together. So I've always been very confused that people would say, you know, they're different and competing approaches.

Speaker 3: Yeah, I see more and more just in different kind of people's approaches and philosophies, a kind of a hybrid of the two, where we've got a Kanban board, but still following the kind of structure of Scrum.

Speaker 2: Yeah, and I think that's exactly right, Darcy. I think that the use of a Kanban board, and the difference between a Scrum board and a Kanban board is, you know, semantic to some extent. However, if you're not managing, you know, like how long, so you've got aging, then it's probably not going to be a Kanban board. If you've not got WIP limits clearly defined, then it's probably not a Kanban board. And so applying those practices onto your Scrum board to convert it from one to the other, you know, this visual way of work is a really good step because suddenly you'll realize that you've got this particular, you know, PBI or task on the board and it's been there for like nine, you know, nine sprints. It keeps going through the sprint cycle a bit like a bit like a sock in your, in your laundry. You know, you've got that one sock that keeps going through every time because it gets stuck at the back of your washing machine. So, and it's very clear then, because you know, you've got that time sort of measure, those sorts of things are incredibly valuable. So I'm not sure hybrid approach, I think combining these two sets of ideas to what makes sense for you is, is, is ideal. Yes.

Speaker 1: As you can see Kanban and Scrum are different. Scrum is a sprint based software development framework. While Kanban provides a strategy to optimize the flow of value through the development process, but they aren't mutually exclusive. The software development process can be greatly enhanced when the flow based perspective of Kanban is used to enhance Scrum and its implementation.

Speaker 3: Thank you.