“And remember, no matter where you go, there you are.”
– Confucius

Nearly two years ago, I joined PagerDuty as an Agile Coach with limited experience working with Kanban delivery teams. I started coaching two Scrum teams, but as soon as my teams got word that their peers using Kanban were happier and higher-performing, they pushed for the switch.

Today, nearly all delivery teams here have transitioned from Scrum to Kanban. But before we get into why the teams made the switch to Kanban, let’s talk about the culture that enabled them to make that switch in the first place.

How PagerDuty Culture Enabled Teams to Switch to Kanban

There’s a popular quote from 3M’s former president and chairman, William McKnight: “Hire good people, and leave them alone.” PagerDuty’s engineering culture is exemplary of this philosophy. Teams here are self-organizing and largely in control of their own destiny.

While all delivery teams follow Agile principles, some choose Scrum and others Kanban, to manage their day-to-day work. As a team evolves and their work changes, they may choose a different way to get things done. As an Agile Coach, I can help a team determine what’s a good fit for them, but I don’t own their process solution. It’s a journey that, ultimately, the team must take together.

So why did almost all of our teams switch to Kanban? And was it for the right reasons?

Why Most Teams Switched to Kanban

The transition didn’t happen overnight. It started with one team and cross-pollinated across all of Product Development over the course of two years. When team members first heard about their peers’ success using Kanban, they were motivated to try it themselves. Some of their preconceived notions about Kanban were based in reality and others were misconceptions. As an Agile Coach, it was my goal, along with the rest of the Agile Leadership Team, to help our teams get past these misconceptions, and decide whether or not to transition to Kanban for the right reasons.

Misconceptions: Wrong Reasons to Switch to Kanban

Kanban is the ultimate destination for a high-performing team. Both Scrum and Kanban help teams prioritize soonest possible value delivery to customers, and neither is superior to the other. But, within the context of a given team, Kanban is not always the superior choice. At a given point in time, a team will be better served by either Scrum or Kanban.

Kanban means no estimation. Kanban teams typically work toward sizing all their work similarly (e.g., using a “chunk size” of three days or fewer per ticket). This is still an estimate even though it doesn’t use Story Points or a specific time estimate.

Kanban means no more commitments. Kanban does mean no more Sprint Commitments (work commitments made within a 2-4 week timebox), but this doesn’t mean there are no commitments. A Kanban team is accountable to its Cycle Time (the time it takes to complete one ticket), similar to how a Scrum Team is accountable to its committed Sprint Velocity (measure of the amount of work the team completes in a single timebox). Cycle Time is used for both empirical process reflection and release forecasting.

Kanban means less meetings. Kanban recommends certain meetings, but does not prescribe them in the way that Scrum does. That being said, most teams would find it challenging to be successful without organized meetings. Successful teams need to be aligned on goals and build a plan to get there, whether they use Scrum or Kanban.

Most Kanban teams at PagerDuty replaced Story Time meetings with Replenishment (both have the purpose of preparing the team for future work), and continued to hold Retrospectives, Reviews, and Daily Stand Ups. As a team’s backlog still needs to be maintained, some teams also continue to hold Backlog Refinement meetings. Sprint Planning does go away in Kanban.

So while there may be some meeting savings, overall, the change is not significant between Scrum and Kanban.

Realities: Right Reasons to Switch to Kanban

Scrum is less flexible. Scrum uses an iteration as a timebox and scopebox, and there is little flexibility to add or remove work once an iteration has started. At PagerDuty, our teams own what they build, meaning we are a true DevOps organization. By nature of owning what we build, some teams are interrupted with work that needs to be expedited. Scrum views this negatively as a “sprint injection,” which goes against the team’s velocity metrics. Kanban is flexible and allows the team to create a class of service to expedite high-urgency work.

Scrum is more prescriptive. Scrum has more rules to follow and more structure built in. This makes it better suited for a newly formed team, which can use the extra structural support. For more mature teams, the rules of Scrum can start to impede the team and slow them down.

Team and organizational culture matter. Some teams are motivated to make regular internal commitments toward their milestones (e.g., Sprint Commitments). Other teams find this stressful and prefer to improve performance by focusing on improving their Cycle Time. Some teams prefer to manage Work In Progress (WIP) through a Sprint Commitment, other teams prefer to manage WIP by controlling the flow of tickets in the system. Some teams find value in sizing their work using Story Points. Others find that pointing conversations offer diminishing returns, and find that breaking down their work using a Chunk Size (e.g., three days or fewer) is a more efficient process.

Kanban Is Great … But

Teams at PagerDuty are almost all using Kanban today. Agile Coaches helped teams decide if they were making the switch for the right reasons. When teams didn’t transition for the right reasons (e.g., they thought it’d fix a dysfunction going on with Scrum), they soon found out that the discipline, communication, and estimation needed for Scrum were also needed to be successful with Kanban.

Choosing a process for your team involves many facets to consider. I hope that this blog post helps you reflect on your team’s process and identify whether or not a transition to Kanban would actually help your team better achieve their end goals, or if they’d just bring their Scrum problems over to Kanban.

Do you have lessons learned or stories to share about your team’s use of Scrum or Kanban? Share them on our Community page to let us know what works best for your team.

This blog post was inspired by PagerDuty’s Andrea Roberts’ internal blog post “Scrum or Kanban? Choosing the Right Tool for Your Team.”