Message from Mike Cohn
As great as I think Scrum is, I don’t think Scrum is right for every team in every situation.
In some situations, other agile approaches are a better fit. Most commonly that means Kanban.
And so, I’m writing to introduce a guest post on Kanban from Brendan Wovchko, whom I’m happy to call a friend. Brendan is an expert at both Kanban and Scrum. He and I have co-trained together, and I always appreciate his openness to considering each team’s unique situation when advising them.
He knows that Scrum and Kanban each can be best for different situations. And in the following post he’s going to share times when Kanban might be a better choice. Enjoy!
I’m frequently asked by my workshop participants to weigh-in on their team’s debate between Scrum and Kanban. I always find their questions interesting because their assumption is that Scrum and Kanban are somehow enemies.
As an agilist, I value experimentation over prescription. I don’t want someone to tell me what’s best for a specific team, I want to prove it.
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 recognize 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.
Kanban Helps with 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 can be 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.
Kanban Seems Easy but Don't Be Fooled
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.
Kanban Flexes with 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.
Kanban Works for Very 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.
Kanban Handles 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.
Scrum and Kanban Are Both Great Choices
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!
Last update: June 10th, 2025
