From the two previous posts in this series, A Scrum primer for Kanban teams and A Kanban primer for Scrum Teams, you can see that Kanban and Scrum are very compatible. If that’s the case, why do so many people say that one is better than the other?
My hypothesis is that the disconnect comes from the many myths that persist about the two approaches. If we examine and debunk these myths once and for all, perhaps it will finally allow people to embrace their compatibility.
MYTH: Scrum is revolutionary; Kanban is evolutionary
No doubt that introducing the Scrum framework into an environment is likely to shake things up considerably. I’ve heard some suggest that introducing Kanban just encourages existing behaviours (i.e., that it reinforces waterfall). Not true. As Daniel Vacanti explained to me, “The concept of limiting work in progress is revolutionary in most organizations.” As soon as an organization starts visualizing its work, limiting work in progress, and actively managing flow, it disrupts the existing order. It has a similar disruptive effect as the concept of potentially releasable product increments every month (or less) in organizations that start using Scrum.
MYTH: Scrum is for____ and Kanban is for____ (or Kanban is all about manufacturing)
Although Kanban derived many of its lean concepts from the manufacturing sector, they apply equally as well to complex knowledge work. There is nothing inherent in the five Kanban practices that make it incompatible. Visualizing work, limiting work in progress (WIP), actively managing flow, improving collaboratively, and making policies explicit inevitably enhance a team’s ability to solve complex problems.
MYTH: Kanban doesn't encourage teamwork
Many Scrum practitioners see Kanban’s visualized workflow with columns that represent specialized skills as a sign that it encourages working in silos using handoffs. What they are missing is Kanban’s key practice of actively managing flow. No doubt, if done incorrectly, you can have a Kanban process that focuses on individuals completing their tasks and handing them off to the next cog in the machine. However, if you’re truly managing your flow, you will see where the bottlenecks are. The way to alleviate those bottlenecks is to manage the flow of work across the entire value stream. Who manages that flow? It is the people closest to the work---the people in the value stream (AKA a team). Combine actively managing flow with the practice of improving collaboratively, and you naturally end up with cross-functional, self-managing teams of people working together to deliver value.
Yuval Yeret adds that Kanban teams should avoid naming their columns based on the team structure or role. Instead, they should focus on the activity/action/work that’s being performed. This along with WIP limits encourages individuals to swarm to complete the activity.
MYTH: Scrum’s Sprint Planning Event is a time waste
Teams that embrace Kanban often decide to ditch Scrum’s Sprint Planning meeting and instead replace it with just-in-time feature planning. They’ll ask, “What’s the point of planning out all of the work for the next two weeks?” What these teams are missing is that the intent of the Sprint Planning meeting isn’t to create a detailed Sprint plan, but to instead come together as a team to decide what goal to achieve and to come up with a plan to complete that goal. The details of that plan need not include an exhaustive list of work, and it does not need to consume all of your capacity. You’re expected to leave room for uncertainty.
MYTH: Sprints constrain flow
This idea usually stems from two misunderstandings about Scrum. The first is that you can only release to production at the end of the Sprint. This myth became so entrenched that it was addressed in the latest Scrum Guide by explicitly pointing out that Scrum is routinely used in environments where products and enhancements are released many times per day.
The second misunderstanding is that Developers can only work on items specified in Sprint Planning. Nothing in the Scrum Guide stops a team from embarking on new work mid-Sprint as long as it meets two conditions. The first is that the work doesn’t endanger the Sprint Goal. Developers are still committed to its delivery. The second is that the Scrum Team will have a useable and valuable product Increment for the Sprint Review. This means that either the new work will be done by the end of the Sprint or that working on it won’t restrict the Scrum Team from having a useful and valuable Increment at the end of that Sprint.
Ready to move on?
Throughout this series examining how the practices of Scrum and Kanban can complement each other, we’ve made the case that using the two together has the potential to achieve better results for teams. Outdated misunderstandings and persistent myths about both Scrum and Kanban have led many practitioners to believe they have to choose between the two. By dispelling the misconceptions, I’m hopeful we can move on to greater collaboration.
Ta.
Steve Porter
Other posts in the series
- A Scrum primer for Kanban teams, July 12, 2017
- A Kanban primer for Scrum Teams, June 21, 2017
- Scrum and Kanban stronger together, May 10, 2017