(Great article from Mike Cohn of https://www.mountaingoatsoftware.com)
A truly agile team will experiment with a lot of ideas to find which works best, not just adopt the first thing they try. Scrum and Kanban aren’t competitors, they are experiments every team should try.
While that is true, I recognise that many teams have limited liberty to experiment. If you work for an organization that won’t tolerate small failures in order to discover big productivity gains, I understand! If that’s you, I’m willing to bend my rule about prescription and offer some advice on five conditions under which I’ve found Kanban to be a better fit than Scrum.
1. Low Tolerance for Change
Over the years I’ve encountered many organizations that are brittle to change. They’re comfortable with the way they do things even if they aren’t getting results. Their solution isn’t to rethink how they work, it’s usually to make their teams work longer and harder—which isn’t a real solution. Scrum is a threat to brittle, change-adverse organizations primarily because of how quickly it transforms roles and meetings.
Kanban doesn’t use transformative change, it embraces evolutionary change. Kanban employs a start with what you do now mindset that introduces teams to the shallow end of the pool before taking them toward the deep end of maturity. Kanban doesn’t require any changes to roles or meetings when first getting started.
2. Obvious at All Levels
The primary advantage Kanban has over Scrum is that it is immediately intuitive to anyone. A Kanban board is an instant sense-making device. It requires zero explanation to understand. However, Kanban’s primary advantage is also its biggest flaw. It’s easy to be fooled by Kanban’s hidden sophistication. Kanban is far more sophisticated than a simple tool for visualization. Kanban is built for speed but most teams will never master the behaviors that produce those results because their commitment to learning Kanban stops at visualization.
3. Fluid Priorities
Scrum produces the best results when a team commits to a batch of work and is empowered to remain focused for the duration of their iteration. The success of Scrum requires informed and empathetic stakeholders who are bought-in to being agile.
Kanban is able to survive conditions where agile culture doesn’t yet exist because it encourages optionality. A Kanban team prefers to not commit to work in batches and they don’t commit to work until they start it. This means a Kanban team can be maximally flexible to respond to emergencies or changing priorities without needing to renegotiate commitments.
4. Small Teams
The ideal size of a Scrum team is a two pizza team. This ensures that a team is small enough to be efficient and large enough where the time investment in meetings makes sense. If your team is smaller than a two pizza team, Kanban is the best option.
5. Complex Collaboration
Scrum has changed the way the world thinks about work. My favorite attribute of Scrum is the cross-functional team. The idea that a team is comprised of people from different departments and disciplines is a game changer.
In the case of software development, it’s not just engineers and testers anymore. Today, we have user experience, visual design, writing, editing and many other activities.
If your team has a large number of activities, the strategies of sprinting ahead or using a scaling framework may introduce unnecessary complexity and delay.
Kanban doesn’t utilize time boxing to create predictability, it uses lead time—so it is capable of sustainably supporting an unlimited number of activities and collaborations.
I’d continue to encourage you to resist the idea that Scrum and Kanban are competitors or enemies. Both are a means to help teams and their stakeholders achieve sustainable success. Don’t assume that whichever you best understand or most frequently use is superior. Adopt a true agile mindset and experiment with both!