Four Wrong (and One Right!) Reasons to Shift from Scrum to Kanban

I’ve observed different teams transitioning from Scrum to Kanban in search of greater efficiency. Unfortunately, I believe some of them make this shift for the wrong reasons. My focus here is on product teams; service teams are typically not Scrum users.

Before you peg me as a Scrum-over-Kanban advocate, let me clarify: I agree that Kanban can be a more efficient framework than Scrum. However, achieving this efficiency requires better practices. Scrum is an excellent entry point to agility because it encourages teams to deliver small increments at a steady cadence. In this sense, Scrum is like a crutch (or a baby’s swim vest, if your kids are learning to swim). And that’s perfectly fine! Also, I’ve yet to see a team genuinely using Scrumban and solving the problems I outline here. Happy to be proven wrong, though!

Now, let’s dive into the reasons:

First Wrong Reason: “Priorities Change Too Often, and Kanban Is More Fluid”

While this rationale seems valid on the surface, teams often address the symptom, not the root cause. Constantly changing priorities negatively impact both Scrum and Kanban. The difference? In Kanban, these impacts are harder to spot.

Try this instead: Understand why priorities are changing. Highlight the waste caused by shifting focus. Examine the half-baked solutions that failed to create value. Addressing the root cause of constant change is far more impactful than merely switching frameworks.

Second Wrong Reason: “We Can’t Deliver a Goal (or Increment) in Two Weeks”

This argument also seems reasonable at first glance. I’ve heard complaints like, “It’s impossible to deliver a Sprint goal in two weeks with such legacy code!” But again, this addresses the symptom, not the cause. Challenging contexts can be frustrating, but it’s about adjusting expectations. Ron Jeffries famously said, “If you can’t get everything ‘done’ at your current Sprint length, consider shortening your Sprint. If it’s two weeks, try one week.”

Try this instead: The problem isn’t the goal; it’s the volume of work and lack of focus. Reduce the workload and WIP (Work in Progress). If your team is still pressured to deliver unrealistic amounts of work within a set time frame, that’s the real issue.

Third Wrong Reason: “Kanban Is Easier”

This one’s a classic. The tricky part is defining “easy.” If Scrum is a baby’s swim vest, Kanban is like throwing your baby straight into the pool. Sure, the swim vest is clunky, and the baby might complain. But once they’re in the water without it, they’ll likely panic. If you’re not implementing WIP limits, revising your workflow, and maintaining a cadence of feedback loops, then you’re not swimming in a pool—you’re splashing in a puddle.

Try this instead: Apply WIP limits and feedback loops within Scrum. Experiment with these practices in a Scrum context to observe their benefits before considering a full transition to Kanban.

Fourth Wrong Reason: “We Have to Deal with Support Alongside Planned Work”

Here’s how the story usually goes: “We delivered our new service or functionality, but now we’re bogged down with support tasks like handling corner cases, manual interventions, or fixing things that didn’t quite work as planned. This unplanned work disrupts our cadence, and we never deliver as planned.”

Try this instead: Different types of work require different approaches. Mixing planned work and support tasks on the same board or with the same team isn’t ideal. Explore solutions like separate boards or dedicated teams (or a mix of both). The Project Management Stack Exchange community has excellent discussions on this topic. I’d suggest this and this so I won’t delve into the details.

The Right Reason: “Scrum Is Limiting Our Delivery”

Scrum has a fixed cadence, a concrete Sprint goal, and defined roles. If your team is already delivering value beyond the fixed cadence—achieving multiple goals in just a few days—and the roles are more indicative than enforced, Scrum might indeed be limiting your potential. In this case, your team is likely ready for a more fluid approach to delivering value.

Final Thoughts

Each team has unique dynamics and challenges. Experimenting with different frameworks is more important than worrying about making the “wrong” change. Follow the Shu-Ha-Ri approach: practice the basics, then evolve your model. Iterate. Fail fast, learn faster—and have fun along the way!