Kanban Solves the Problems Scrum Creates

Scrum starts with an optimistic view of work.

Work arrives as user stories. Someone can describe each story clearly enough for a team to understand it, a Product Owner can order the stories by priority, the team can estimate them, and a cross-functional team can deliver a selected group within a sprint. At the end of the sprint, the team can inspect what it made and adjust the plan for the next one.

That is a useful model when the work behaves that way.

The trouble is that a lot of work does not.

In complicated environments, the work may require specialised knowledge, several teams, external approvals, or a sequence of technical decisions that cannot be known in advance. In complex environments, the problem itself may not be clear until people try something. Customer needs change. New information changes the solution. Dependencies appear. The work crosses organisational boundaries that the Scrum team does not control.

A user story can still be a useful representation of work in these conditions. But the story does not make the work small, independent, predictable, or deliverable inside a sprint.

When the model and the work do not match, organisations rarely question the model first. They usually try to make the organisation conform to it.

When the optimistic model breaks

A team plans a sprint and discovers that several stories are waiting for design, security, legal, another team, or a decision from a manager. The team carries unfinished work into the next sprint. Priorities change halfway through the sprint. A story turns out to describe a symptom rather than a solution. The team completes the development work but cannot release it because the rest of the system is not ready.

The sprint review shows partially finished work. The retrospective identifies the same problems the team discussed last time. The next planning session starts with a mixture of new work, old work, urgent requests, and explanations for why the previous plan did not hold.

None of this necessarily means that the team is incompetent or that people do not understand Scrum. It may mean that the work does not fit the assumptions that Scrum asks the organisation to make.

But organisations tend to interpret the gap as a defect in execution:

• The stories are not refined enough.
• The estimates are not accurate enough.
• The team is not committed enough.
• The Product Owner is not prioritising well enough.
• The Scrum Master needs more training.
• The team needs to follow the process more consistently.

These explanations are attractive because they preserve the model. If the problem is the people or the process, the organisation can fix the people or the process and keep the sprint system intact.

The idea of a Scrum team seems great in theory, but making it work asks a great deal of the team. The team needs to estimate its work. It needs to sprint, sizing work so that it fits inside the sprint. It needs to commit to what it has selected. It needs to adopt particular roles, refine stories to a suitable shape, and run the events the framework prescribes. When teams face issues, all of this gives them a path forward: adapt how they work to make the framework work.

That path is part of the problem. It gives teams an alternative to reflecting on the reality of their situation and to making the kinds of changes that represent real agility, which is what the organisation wanted when it adopted Scrum in the first place. All of that effort goes into conforming to the framework, but none of it increases agility. The question of whether the framework fits the work never comes up.

The control response

Once an organisation treats the mismatch as a quality or discipline problem, control starts to accumulate.

Teams are asked to produce more detailed acceptance criteria, split stories into smaller pieces, estimate more carefully, and report progress more frequently. Managers introduce dashboards, velocity targets, burndown charts, status meetings, dependency trackers, and escalation paths. Someone reviews whether every ticket is in the right state. Someone else checks whether the team has enough work ready for the next sprint.

The organisation measures more because it does not trust the system to produce a clear signal. It standardises more because variation feels like a source of risk. It micromanages more because the sprint commitment has become a promise that somebody must enforce.

This creates a strange situation. Scrum was adopted to help an organisation respond to uncertainty, but the response to uncertainty becomes increased measurement, standardisation, and control. The team has more process around the work, yet less ability to respond to what the work is actually telling them.

The additional control also creates the very behaviours that make delivery harder. People optimise for keeping stories moving rather than finishing valuable work. They split work to improve the appearance of progress. They avoid difficult items that might threaten the sprint goal. They hide uncertainty until it becomes impossible to ignore. They spend time explaining the system instead of improving it.

Then these behaviours become further evidence that the team needs more control.

The problem is bigger than the team

Scrum places much of the responsibility for delivery on a team, but the conditions for delivery are usually distributed across the organisation.

The team may not control how work enters the system. It may not control the order of competing requests. It may not control the dependencies that interrupt its work. It may not control the policies that determine when work can move from one stage to another. It may not control staffing, architecture, funding, approvals, or the availability of specialists.

Yet the team is still expected to make a credible sprint commitment.

This is how organisations end up blaming teams for system problems. The team is held accountable for delivering a fixed selection of work in a fixed period, even though the team does not control the flow of that work from idea to outcome.

The result is frustration for everyone involved. Leaders do not get the predictability they expected. Product Owners are pressured to create certainty from uncertain information. Scrum Masters are asked to improve a process that does not include the main constraints. Teams are told they are empowered while being measured against commitments they cannot reliably control.

Everybody is working harder to make an optimistic model true.

Start with the flow of work

Kanban takes a different starting point. It does not ask an organisation to pretend that work is more predictable, independent, or controllable than it is. It asks the organisation to make the existing work visible, understand how it moves, and improve the system that delivers it.

That means looking at the whole service, not just the team’s current sprint. Where does work come from? How is it selected? Where does it wait? What causes it to be blocked? Which policies determine whether it can move forward? Where do decisions, handoffs, and dependencies slow delivery down?

The answers are often uncomfortable because they move attention away from individual productivity and toward the design of the system. A queue may be too large. Work may be started before the necessary information is available. Too many items may be in progress. A specialist may be a bottleneck. An approval step may be creating a large batch of waiting work. Several teams may be sharing one constrained capability.

A Kanban board makes these conditions visible. Work-in-progress limits create a reason to finish before starting more. Explicit policies make the system discussable. Flow metrics such as throughput, work item age, and cycle time show what the system is actually doing rather than what a plan predicted it would do.

This does not make complicated or complex work simple. It gives the organisation a better way to work with the uncertainty that is already there.

Cadences can stay, commitments can change

Choosing Kanban does not require abandoning every Scrum event. Teams can still meet regularly to replenish work, review outcomes, discuss improvements, and coordinate with stakeholders. A biweekly review or retrospective can be useful even when work is not contained inside a two-week sprint.

The important change is what the cadence means.

A sprint is often treated as a container: work is selected for the period, the team commits to it, and unfinished work is treated as a failure of planning or execution. In a flow system, the same two-week meeting can be a checkpoint for observing the work. The team reviews what finished, what is aging, what is blocked, what entered the system, and what should be pulled next.

The rhythm remains. The fiction that the work will fit neatly inside the rhythm does not.

That distinction removes a great deal of unnecessary pressure. The organisation can maintain a regular feedback cycle without turning every planning period into a delivery contract.

Kanban solves the problems Scrum creates

This is the provocative claim, but it is also the practical one: Kanban solves the problems Scrum creates.

Scrum creates pressure to turn uncertain work into sprint-sized commitments. Kanban makes uncertainty visible and manages the flow of work through it.

Scrum encourages organisations to explain missed commitments through better estimates, better stories, and better discipline. Kanban asks what in the system caused work to wait, age, or stop moving.

Scrum makes a team responsible for delivering work that may depend on the wider organisation. Kanban makes the wider workflow visible so that the organisation can address its constraints.

Scrum gives organisations a process to implement. Kanban gives them a method for improving the way work is already delivered.

This does not mean that every organisation using Scrum will experience these problems, or that Kanban automatically fixes them. A Kanban board can become another status report. Metrics can become targets. Work-in-progress limits can be ignored. The method only helps when people use it to learn about and change their system.

But the direction is different. Scrum asks the organisation to fit its work to an optimistic delivery model. Kanban starts from the work as it is and helps the organisation build a more realistic, more capable system around it.

That is why Kanban is not merely an alternative framework. For organisations frustrated by the problems Scrum has created, it is a way to stop solving the wrong problem.