Can teams mix and match Scrum and Kanban, or are those two project management frameworks mutually exclusive? Many Agile teams combine principles and practices from both Scrum and Kanban, evolving an approach that works best for their unique situation. In practice, Kanban and Scrum have much in common.
A key factor in the success of Scrum and Kanban is that development teams direct their own work, guided by business priorities. Both approaches promote respect for people, allowing them to do their best work, providing servant leaders to help remove impediments to continual improvement. Members of both Scrum and Kanban teams manage their own workloads. They establish their own rules for determining when a user story is ready to deliver to production.
Both Kanban and Scrum teams “pull” in work, rather than having management assign tasks to individuals. Scrum teams pull the highest priority user stories from the business product backlog, break each one down into small tasks, estimating the tasks and stopping when they’ve reached the amount of work to which they can commit for that time period.
Rather than plan an iteration in advance, Kanban teams determine how many user stories they can work on at any given time. They pull in stories until all their “work in process” (WIP) slots are full. As one user story is completed, freeing up a WIP slot, the next highest priority story that is ready for development is pulled in. Kanban teams plan, but they may choose to do it weekly, or when they’re running out of stories that are ready to pull in. They may release to production at a set frequency, like a Scrum team, or they may release as soon as a minimal marketable feature (MMF) is ready.
Limiting WIP, pulling stories in, and maintaining a continuous flow are not the most important practices of Kanban in software development. As Kenji Hiranabe has pointed out, software development isn’t the same as manufacturing. Development teams create something new every time, they don’t produce the same thing over and over. Per Hirinabe, Agile Kanban emphasizes the self-directing, visual and Kaizen properties of Kanban. These help make the flow of work visible, and help teams continually improve their development process. This is the foundation of Agile development, regardless of the “flavor” you prefer.
Both Scrum and Kanban leave the choice of development practices up to the development team. Core development practices including continuous integration, test-driven development and acceptance test-driven development or specification by example have been widely adopted, even by teams that don’t self-identify as “Agile.”
Scrum and Kanban teams both use short feedback loops to evaluate results and make adjustments. Scrum calls for a retrospective after each sprint, whereas Kanban leaves retrospective frequency up to the team. I’ve worked on a Kanban team that did story retrospectives, which provide quick inspect-and-adapt opportunities. Scrum teams should also feel free to do more frequent retrospectives.
Work in process
Perhaps the most obvious difference between Kanban and Scrum is in limiting work in process versus planning delivery in intervals of iterations. In practice, though, the differences tend to melt away. Though Scrum doesn’t call for formally limiting WIP, having several stories underway at the same time adds to the risk that no stories are finished by the end of the sprint. Let’s say you planned to deliver five stories. Having three finished and ready to release at the end of the sprint beats having five half-finished and nothing to deliver. Scrum teams must focus on finishing one story at a time, effectively limiting their WIP.
What does it mean to focus on one story at a time? Let’s say Story #1 is all finished except for a database task and a test automation task. A programmer working on Story #2 can step up and say, “I’ll do that database task so that we can finish this story”, while another programmer and a tester working on Story #3 stop work on that story to pair up on finishing Story #1’s test automation task. Story #1’s needs take precedence over the subsequent stories. Once it’s done, we know we can deliver it to production, we don’t have to think about it anymore, and we can move on to the next priority story.
Scrum’s framework calls for estimating stories and tracking team velocity, the number of story points done each sprint. As Henrik Kniberg and Mattias Skarin explain in their book, Kanban vs. Scrum: Making the most of both (2009), Kanban doesn’t prescribe estimating or using velocity. However, any Agile team needs some way to help the business plan when certain features might be delivered, knowing that plans always change. Some Kanban teams track how many features were delivered per week, or the average time to complete each minimum marketable feature (MMF). Others adopt a Scrum-like approach to estimation and velocity. Kanban teams may hold planning meetings as needed, to prepare more stories for development, or they may plan at a regular frequency, as Scrum teams do.
My own Scrum team has evolved more towards Kanban and Lean approaches to planning. When we first adopted Scrum, we did traditional sprint planning, committing to delivering a specified set of user stories at the end of the sprint. Though we usually delivered what we planned, we realized that this “commitment” idea did not help us in any way. We are committed to doing our best work all the time, so “committing” to a certain amount of work doesn’t make us work harder or better. Stuff happens, even when you plan in two-week iterations. We plan enough stories to keep us busy for at least a few days, and when we’re confident that we can bring more stories in, we have another planning session.
Scrum provides for a product backlog of user stories, whose cost has been estimated by the development team, and which are prioritized by the business. If the backlog isn’t “groomed” vigorously, removing stories which will never get to the top of the priority list, it becomes a burden. When our team had been practicing Scrum for three years, we had two big shoeboxes full of story cards that were never going to be pulled into a sprint. That’s not a way to make business value visible.
Kanban follows Lean principles, and queues of work such as product backlogs are seen as waste. Our Scrum team decided to adopt a Kanban-style approach, and we dumped our big product backlog. Our stakeholders may make general plans for big themes starting a few months before development work will start, but actual user stories are only planned for the next iteration, and sometimes are planned during the iteration.
Both Kanban and Scrum provide proven patterns and practices to help software teams deliver business value in a timely manner, allowing teams to work at a sustainable pace. Both provide ways for teams to use feedback frequently to try small experiments to address impediments and continually improve.
A team that’s new to Agile may find it more straightforward to start with one model or framework, implement it “by the book,” and then use retrospectives to evaluate where improvements can be made. Don’t hesitate to experiment with ideas from other frameworks and models than the one with which you start. Agile development is all about finding better ways to do our best work.
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.