I have always found the analogy of owning vs. renting a useful tool for exploring the differences between Scrum and Kanban. Although neither the Scrum Framework nor the Kanban Method are “processes,” teams use them as a basis for creating their processes, and, in my experience, teams starting with Kanban generally have a stronger sense of ownership for their process than Scrum teams do. Why is this? And what are the implications?
“Start with Where You Are”
Effective Agile teams inspect and adapt their approach to tailor it to their context. They develop customizations, such as the format and content of their user stories and acceptance criteria, definitions of “Ready” and “Done,” the timing, ownership, and format of particular ceremonies, and the ways in which they work together (usually captured in a working agreement). It is particularly important for teams to apply this same approach to inspecting and adapting their process and its associated roles, so that they can tailor it to their unique circumstances. Both Scrum and Kanban allow for this, but Kanban tends to make it easier.
The essence of the Kanban Method is to “start with where you are.” Teams begin by applying a visualization to their current work and method of working. When they are ready, they introduce work in process (WIP) limits to effectively manage flow. These changes provoke improvements without disrupting established patterns or threatening existing roles. Once effective metrics are in place, the result is a continually improving, customized process that reflects the accumulated knowledge and experience of the team.
Inspection, Adaptation, and Immutability
The most effective Scrum teams evolve in a similar way. However, the Scrum Framework can be one of the largest obstacles to getting there. It has explicit roles, ceremonies, artifacts, and rules, which the Scrum Guide describes as “immutable.”[1] This can create the belief that there is a “right” way to implement the Framework, and that all other permutations are incorrect; incorrect implementations are often derided as “Scrum-but.”
There are two unfortunate results. The first is a tendency to waste effort arguing about the team’s process and how closely it adheres to the “right” way to do Scrum. The process may be the best fit for the current context, but if it doesn’t adhere to the guidance, some will call it “Scrum-but” and argue to change it. The second is even more insidious. Some team members give up on inspection and adaptation because they don’t feel responsibility for the process. They didn’t create it; it didn’t emerge from their context, so they lack the sense of ownership to customize it.
Rules vs. Principles
Both of these unfortunate results have the same underlying cause. Scrum provides specific, detailed guidance about how to create an empirical process for knowledge work. This is one of its great strengths. But that specificity comes at a cost, and many teams will grow beyond the guidance—the “rules”—of Scrum once they learn more about their particular circumstances. That transition moment can be a critical one. Will the team feel empowered to use their knowledge and adapt beyond the framework, or will they reject their experience and try to adhere to the “rules?”
Kanban teams never face this choice. Kanban deliberately avoids rules and instead focuses on principles. From the very beginning, teams have to determine how they will apply these principles in their environment. They add the specifics necessary to turn the Kanban Method into a customized workflow; this gives the team a strong sense of ownership because when they do that they create their own process. It is natural for them to continue to evolve and change it as they grow and learn.
What Should You Do?
If you’re thinking about using Scrum or Kanban, this difference is important. Do you think your team would benefit from Scrum’s greater level of specificity? Would it help them deliver value more quickly? Or would it be more effective to harness their creativity and allow them to co-create a process with Kanban? Remember that the choice is not one or the other; many teams have leveraged both Scrum and Kanban together to create effective, contextually sensitive processes. Your team can too! As you think about how best to do that, keep the concept of “ownership” in mind.
Read More
This blog post is part of our “Scrum vs. Kanban” series, triggered by a working session at one of Excella’s Agile Coaching Circle’s offsite meetings. We explored our experiences with and thoughts about the Scrum Framework and Kanban Method, identifying a series of themes that would enhance the knowledge and understanding of our colleagues. We are pleased to share those lessons with you.
- Scrum vs. Kanban vs. Scrumban – Jaap Dekkinga
- Scrum vs. Kanban: Impact to WIP – Nicole Spence-Goon
- How Do Technical Practices Fit In Kanban – Paul Boos
- Scrum vs. Kanban: “Renting vs. Owning” the Process – Trent Hone
- My Experience with Kanban Outside IT – Mark Grove
- Reflecting on Agile Principles – Jaap Dekkinga
- How do Scrum & Kanban create Psychological Safety? – Nicole Spence-Goon
- Scrum vs. Kanban: Management’s Explicit Invite – Paul Boos & Trent Hone