Switching from Scrum to Kanban won’t (necessarily) save you
You're tasting the same jam.
A few days ago, Mike Bowler shared a fascinating psychology experiment. Participants taste jam from two jars and pick the one they prefer. The experimenter then secretly switches the jars and asks them to taste their “chosen” jam again. Most people don’t notice. They taste the jam they originally rejected and confidently explain why it’s the better one.
This is what happens when some teams switch from Scrum to Kanban.
A team struggles with Scrum. Sprint planning feels pointless. Retrospectives produce nothing. Velocity is treated as a performance metric. They estimate in story points. Standups are boring status reports. Someone reads a LinkedIn post about how “sprints are dead,” and the team decides to make the switch. They rip out the sprints, put up a Kanban board, and carry on.
Nothing actually changes. The same dysfunctions are still there, running underneath a different label. The planning is still vague. The feedback loops are still weak. The problems to solve are still unclear. The team has picked up the other jar and is now confidently defending why this jam tastes better. It’s the same jam. They just can’t tell, because they never understood what they were tasting in the first place.
This article is about why that happens. It’s about what agile frameworks actually do, what most people get wrong about Scrum, what most people get wrong about Kanban, and why the conversation about switching between them is almost always asking the wrong question.
Frameworks are mirrors, not medicines
Here’s the most important thing I can tell you about any agile framework: it doesn’t fix your problems. It makes your problems visible.
A sprint that feels painful isn’t painful because of the sprint. The sprint is showing you something. Maybe your team can’t finish anything in two weeks because the work isn’t broken down properly. Maybe planning feels like fiction because nobody actually understands the requirements. Maybe the demo is embarrassing because the team built something nobody asked for. These are not sprint problems. These are organisational problems, team problems, requirements problems. The sprint is the mirror.
When you remove the mirror, you don’t fix the dysfunction. You just stop seeing it.
This is the role agile frameworks play. Scrum’s ceremonies create regular, unavoidable moments where reality has to be confronted. Did we build the right thing? Are we improving? Can we actually finish what we started? If the answers are uncomfortable, the instinct is to blame the framework. But the framework is just the thing that forced you to ask.
Kanban does the same thing, by the way. A Kanban board with a massive pile of work-in-progress is a mirror showing you that your team can’t say no and can’t finish things. WIP limits that keep getting overridden are a mirror showing you that your organisation doesn’t respect capacity constraints. The question is never “which mirror do I want?” The question is “am I willing to look at what the mirror shows me?”
Most teams that switch from Scrum to Kanban aren’t choosing a better mirror. They’re choosing a less confrontational one. Sprints force you to face reality every two weeks whether you like it or not. Kanban is gentler about it. That’s not always an advantage.
Everything you think you know about Scrum is probably wrong
I’ve coached teams for years, and the number of misconceptions about Scrum is staggering. Most teams that say they’re “doing Scrum” are doing something else entirely, and most teams that say Scrum doesn’t work have never actually tried it. Let me go through the big ones.
Sprints are mini-waterfalls. This is the most common misconception and it’s completely wrong. A sprint is not “two weeks to build what we planned.” A sprint is a timebox for learning. The Sprint Goal gives direction, but the team is expected to discover things along the way, adjust their approach, and deliver the most valuable increments they can. If your sprints feel like waterfall, the problem is how you’re running them, not the concept itself.
Story points are part of Scrum. They’re not. Read the Scrum Guide. Story points appear nowhere in it. Story points are a widespread practice that became associated with Scrum through cultural osmosis, but Scrum doesn’t prescribe any estimation technique. If your story point discussions are wasting hours every sprint, that’s a choice your team made, not something Scrum imposed on you.
Velocity is a Scrum metric. It’s not. It’s not in the Scrum Guide at all. Velocity became widespread through tools like Jira and through management’s desire for predictability metrics. In practice, it’s an antipattern. It incentivises gaming, it conflates output with value, and it gives the illusion of measurement where no real measurement exists. Scrum asks teams to forecast what they can accomplish in a sprint. It doesn’t say how. If your organisation is using velocity as a performance measure or a commitment mechanism, that’s a dysfunction your organisation created, not something Scrum asked for.
You can’t change direction during a sprint. Wrong. The Sprint Goal provides focus, but the Scrum Guide explicitly says the scope of the sprint can be clarified and renegotiated with the Product Owner as more is learned. If something urgent comes up on Monday, nothing in Scrum prevents you from addressing it. If your team feels locked in, the problem is your interpretation, not the framework.
The daily standup is a status report. It’s not. The Daily Scrum is a planning event. Its purpose is for the developers to inspect progress toward the Sprint Goal and adapt their plan for the next 24 hours. It’s not “tell the Scrum Master what you did yesterday.” If that’s what it’s become, you’ve turned a collaborative planning session into a reporting ceremony. The framework didn’t do that. You did.
The Scrum Master is a project manager. The Scrum Master has no authority over the team. They don’t assign work, they don’t track progress, they don’t manage resources. They serve the team by helping remove impediments and by coaching the organisation on Scrum. If your Scrum Master is acting as a project manager, you don’t have a Scrum Master. You have a project manager with a different title.
Retrospectives are blame sessions or wastes of time. If your retrospectives produce nothing, the problem is psychological safety, facilitation, or follow-through. The retrospective exists so the team can inspect how the last sprint went and make concrete improvements. If nobody speaks honestly, that’s a trust problem. If actions are identified but never implemented, that’s a commitment problem. The retrospective is the mirror showing you those problems exist.
Scrum requires a specific team structure. Scrum requires the team to be cross-functional, meaning the team as a whole has all the skills needed to deliver. It does not mean everyone does everything. A team can have specialists. The requirement is that the team doesn’t depend on external groups to complete their work.
Scrum is rigid and prescriptive. Scrum is actually a minimal framework. The Scrum Guide is 13 pages long. It defines three roles, five events, and three artefacts. Everything else, including story points, velocity, burndown charts, task boards, estimation techniques, and technical practices, is something teams and organisations have added on top. Most of the rigidity people complain about isn’t Scrum. It’s the layers of process their organisation built around Scrum.
Scrum doesn’t allow for technical excellence. This one is particularly frustrating. Scrum doesn’t prescribe technical practices because it’s a project management framework, not an engineering framework. But nothing in Scrum prevents you from doing test-driven development, pair programming, continuous integration, refactoring, or any other XP practice. In fact, the Scrum Guide explicitly states that the Scrum Team is expected to maintain a high-quality Definition of Done. If your Scrum implementation ignores technical quality, you’ve chosen to do that.
The Product Backlog is a list of requirements. The Product Backlog is an ordered list of what might be needed to improve the product. “Might” is doing a lot of work in that sentence. It’s not a specification document. It’s a living, evolving artefact that reflects current understanding. If your backlog is being treated as a fixed requirements list, you’ve lost the plot.
Burndown charts are required. Not in the Scrum Guide. Use them if they help. Don’t use them if they don’t. They’re a tool, not a mandate.
Sprints prevent continuous delivery. This is completely false and I’ll address it in detail later. The sprint is a planning and learning boundary, not a release boundary. You can deploy as often as you like within a sprint.
The common thread in all of these misconceptions is that teams confuse the accretions of corporate Scrum with actual Scrum. They rebel against story point negotiations, velocity tracking (an antipattern that Scrum never asked for), burndown charts, and rigid sprint commitments, and they think they’re rebelling against Scrum. They’re not. They’re rebelling against a cargo cult version of Scrum that their organisation created.
The six practices of Kanban and why you must respect them
Here’s where things get ironic. Most teams that switch from Scrum to Kanban because Scrum felt “too prescriptive” end up doing Kanban in a way that ignores most of what Kanban actually requires.
The Kanban Method, as defined by David Anderson, has six core practices. They’re not optional. They’re not suggestions. If you’re ignoring them, you’re not doing Kanban. You’re just not doing Scrum.
Visualise the workflow. This means making the entire flow of work visible, from the moment something is requested to the moment it’s delivered. Not just “To Do, In Progress, Done.” The real workflow, with all its stages, queues, and handoffs. Most teams put up a three-column board and call it Kanban. That’s not visualising your workflow. That’s hiding your workflow behind a simplified picture.
Limit work in progress. This is the single most important practice in Kanban, and it’s the one most teams ignore. WIP limits exist because starting many things and finishing few things is the primary cause of slow delivery. When you limit WIP, you force the team to finish things before starting new ones. This creates flow. Without WIP limits, you don’t have Kanban. You have a to-do list on a wall. And here’s the critical part: WIP limits must be respected. If your WIP limit is 3 and you have 5 items in progress, you don’t have a WIP limit. You have a decoration. The moment WIP limits become negotiable, you’ve lost the core mechanism that makes Kanban work.
Manage flow. Kanban requires you to actively monitor and manage the flow of work through the system. This means measuring lead time, cycle time, throughput, and identifying bottlenecks. It means paying attention to where work gets stuck and taking action to unblock it. If you’re not measuring flow, you have no idea whether your system is improving or degrading. You’re flying blind.
Make process policies explicit. This means writing down the rules. When is an item ready to be pulled into the next stage? What does “done” mean? Who can override a WIP limit, and under what conditions? Most teams that adopt Kanban operate on implicit assumptions that nobody has agreed to. This leads to exactly the kind of confusion and conflict they were trying to escape by leaving Scrum.
Implement feedback loops. Kanban specifies several feedback loops, including daily standup meetings, service delivery reviews, operations reviews, and risk reviews. Yes, you read that correctly. Kanban has regular meetings. If you switched to Kanban because you wanted fewer meetings, you’ve misunderstood the method. The feedback loops in Kanban serve the same purpose as the events in Scrum: they force you to inspect reality and adapt.
Improve collaboratively, evolve experimentally. Kanban emphasises continuous improvement through small, incremental changes based on evidence. This means you need retrospectives, or something functionally equivalent. You need to regularly examine your process, identify problems, try experiments, and measure results. If you switched from Scrum to Kanban and stopped doing retrospectives, you’ve removed your improvement mechanism.
Do you see the irony? Teams abandon Scrum because they find it too structured, then adopt Kanban while ignoring the structures that make Kanban work. The result is a team with no sprints, no WIP limits, no flow metrics, no explicit policies, no feedback loops, and no improvement process. That’s not Kanban. That’s anarchy with a board on the wall.
Why switching without understanding solves nothing
The core fallacy in the “Scrum to Kanban” narrative is the assumption that the framework is the problem. It almost never is. The problems are usually one or more of the following:
The organisation treats agile as a project management methodology rather than a product development approach. Work is pushed onto teams rather than pulled. Success is measured in output rather than outcomes. Management wants predictability but won’t invest in the conditions that create it. Teams don’t have the skills, autonomy, or psychological safety to self-organise. Requirements are vague and nobody has the authority or willingness to clarify them. Technical debt has accumulated to the point where every change is slow and risky. Dependencies between teams create bottlenecks that no process framework can solve.
None of these problems are caused by sprints. And none of them are solved by removing sprints. If you switch from Scrum to Kanban while carrying all of this baggage, you’ll get the same results with a different board layout.
The honest conversation isn’t “should we use Scrum or Kanban?” It’s “what are the actual problems we need to solve, and which practices help us solve them?”
Scrum and Kanban are not opposites
The framing of Scrum versus Kanban is fundamentally wrong. They’re not competing philosophies. They’re complementary sets of practices that address different aspects of the same challenge: how to deliver valuable software in the presence of uncertainty.
Scrum provides a cadence. Regular moments for planning, review, and adaptation. A timebox that creates urgency and focus. Defined roles that clarify responsibility.
Kanban provides flow management. Visualisation of work. WIP limits that prevent overload. Metrics that show whether your system is healthy.
There is nothing stopping you from using both. In fact, the most effective teams I’ve worked with do exactly that. They use sprints as planning and learning cycles while also applying WIP limits within those sprints. They visualise their workflow on a Kanban board while maintaining the Scrum cadence of Sprint Reviews and Retrospectives. They measure flow metrics like cycle time and throughput alongside sprint-based metrics. They treat the sprint as a feedback loop and the Kanban board as a diagnostic tool.
This integration is sometimes called Scrumban, and while the name is clumsy, the idea is sound. Take the useful parts of both. Timeboxes and WIP limits. Sprint Reviews and flow metrics. Retrospectives and explicit policies. The goal is not to pick a camp. The goal is to assemble a set of practices that helps your team deliver effectively.
The question is never “Scrum or Kanban?” The question is “what combination of practices makes our specific problems visible and gives us the feedback we need to improve?”
Continuous delivery works with both, and most teams do neither
One of the strangest arguments in the “sprints are dead” discourse is the idea that sprints prevent continuous delivery. This betrays a fundamental misunderstanding of what a sprint is.
A sprint is a planning boundary, not a release boundary. The Scrum Guide says the increments must be usable by the end of the sprint. It does not say you can only release at the end of the sprint. You can deploy to production every day, multiple times a day, within a sprint. Many teams do. In fact, the Scrum Guide encourages readers to do that: “Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.”
Continuous delivery is a technical capability. It requires automated testing, continuous integration, a deployment pipeline, feature toggles, and an architecture that supports independent deployment. These are engineering practices. They’re independent of whether you use Scrum, Kanban, or anything else.
If your team can’t do continuous delivery, switching from Scrum to Kanban won’t change that. You’ll still have the same manual testing, the same merge conflicts, the same deployment bottlenecks, and the same fear of releasing. Kanban doesn’t give you a deployment pipeline. It doesn’t write your tests. It doesn’t decouple your architecture.
Conversely, if your team can do continuous delivery, Scrum doesn’t prevent it. Deploy whenever you want. The sprint planning still gives you a rhythm for deciding what to work on. The Sprint Review still gives you a moment to inspect what was delivered. The retrospective still gives you a moment to improve.
Continuous delivery is orthogonal to your process framework. It’s an engineering practice, and it works with any framework you choose, provided you invest in the technical foundations that make it possible.
AI changes the speed of writing code, not the nature of risk
The latest twist in the “sprints are dead” argument is AI. The claim goes something like this: AI generates code so fast that delivery is no longer the bottleneck, so we don’t need sprints anymore. We need “context” and “discovery” instead.
Let me be direct about this. This argument confuses writing code with delivering software, and it confuses speed with risk.
Delivery has never been primarily about typing. The time spent writing code has always been a small fraction of the total cost of delivering software. Most of the time goes to understanding what needs to be built, designing a solution, testing it, integrating it with existing systems, deploying it, monitoring it, and supporting it in production. AI can accelerate the coding part. It doesn’t eliminate the rest.
But more importantly, the fundamental challenge of software development hasn’t changed. It’s still risk. Will this feature solve the user’s actual problem? Will it work correctly under real conditions? Will it integrate with existing systems without breaking anything? Will it scale? Will it be maintainable? Will it be secure? Will it comply with regulations?
None of these risks are reduced by generating code faster. If anything, they’re amplified. The faster you can generate code, the faster you can build the wrong thing. The faster you can introduce defects. The faster you can accumulate technical debt. Speed without feedback is not a capability. It’s a hazard.
This is exactly why iterative development exists. Not because coding is slow, but because understanding is incomplete. You build a small thing, put it in front of users, learn from the feedback, and adjust. The speed of the coding step is largely irrelevant to this cycle. What matters is the speed of learning.
AI doesn’t change the need for feedback loops. AI doesn’t change the need for WIP limits. AI doesn’t change the need for regular retrospection. AI doesn’t change the need for explicit process policies. AI doesn’t change the need to manage flow. AI doesn’t change the fact that the biggest risk in software development is building something nobody wants, or building something that doesn’t work in production, or building something that can’t be maintained.
What AI does is make the consequences of poor practices worse. If your feedback loops are weak, you’ll now generate wrong solutions faster. If your requirements process is broken, you’ll now build the wrong thing in minutes instead of weeks. If your testing is inadequate, you’ll now deploy defective code more frequently. AI amplifies whatever practices you already have, good or bad.
The teams that will benefit most from AI are the teams that already have strong practices: clear requirements processes, fast feedback loops, comprehensive automated testing, continuous integration, and the discipline to validate before they ship. These are the teams that can use AI to accelerate the coding step without introducing additional risk, because the rest of their process catches the errors.
The teams that will suffer most are the teams that think AI means they can skip the hard parts. The teams that think “context” replaces testing. The teams that think discovery can be done entirely upfront instead of continuously. The teams that think generating code fast means delivering value fast.
Risk management in software development is the same problem it’s always been. You reduce risk through short feedback cycles, small batch sizes, continuous validation, and close collaboration with the people who will use the software. Sprints do this. Kanban’s WIP limits and flow management do this. Both frameworks, when properly implemented, are risk management tools.
AI doesn’t change what risk is. It just changes how fast you can create it.
The real question
If you’re struggling with Scrum, the answer is not to switch to Kanban. If you’re struggling with Kanban, the answer is not to switch to Scrum. The answer is to look honestly at what the framework is showing you and address the real problems.
Is your planning painful because nobody understands the requirements? Fix the requirements process. Are your retrospectives useless because people don’t feel safe? Build psychological safety. Is your delivery slow because of technical debt? Invest in engineering practices. Are your WIP limits constantly overridden because management keeps pushing work in? Have an honest conversation about capacity.
The framework is the mirror. The dysfunction is yours. Changing the mirror won’t change what it’s reflecting.
Stop debating frameworks. Start fixing the problems the frameworks are showing you.