There’s a tendency in engineering teams to treat Scrum and Kanban as ideological choices.
They’re not.
They’re operating models. Tools. And like any tool, the only thing that matters is whether they help you deliver predictably, safely, and without unnecessary drama.
If you’re running a regulated platform, or anything at scale, the real question is:
What kind of work are we dealing with, and what behaviour do we need from the system?
Start With the Nature of the Work
Before picking Scrum or Kanban, you need to understand what’s actually flowing through your system.
Most teams deal with a mix of:
- Planned product development
- Unplanned operational work
- Stabilisation and reliability improvements
- Interrupt-driven support and incidents
Where teams go wrong is trying to force all of that into a single delivery model.
That’s where things start to creak.
Where Scrum Works Well
Scrum is at its best when the work is:
- Predictable enough to batch
- Outcome-driven
- Aligned to a clear product goal
- Relatively protected from interruption
In practical terms, when you can say:
“We believe we can deliver this set of outcomes over the next two weeks, and we’re willing to commit to that.”
Scrum works well for:
- New feature development
- Product roadmap delivery
- Defined refactoring initiatives
- Greenfield or controlled builds
What Scrum gives you
- A forcing function for commitment and focus
- A cadence for stakeholder alignment
- A structure for measuring delivery predictability
But—and this is the key—Scrum assumes a level of system stability.
If your team is constantly interrupted, Scrum breaks down quickly.
You’ll see:
- Half-completed sprints
- Rolled-over work
- Commitments no one believes in
At that point, you’re not doing Scrum. You’re creating reporting theatre.
Where Kanban Comes Into Its Own
Kanban is built for a different reality.
It assumes:
- Work arrives unpredictably
- Priorities shift
- Interruptions are normal
- Flow matters more than commitment
This aligns directly with:
- Platform stabilisation
- Production support environments
- Incident-heavy systems
- Legacy modernisation programmes
- Continuous improvement work
What Kanban gives you
- Visibility of work in progress (WIP)
- Control over throughput
- Faster prioritisation decisions
- A system that absorbs change without collapsing
Instead of committing to batches of work, you focus on:
- Limiting WIP
- Managing flow
- Reducing cycle time
- Continuously reprioritising
The Stabilisation Phase: Why Kanban Wins
If you’re taking over a platform that is:
- Operationally fragile
- Poorly understood
- Carrying hidden risk
- Dependent on key individuals
Then you are not in a Scrum environment.
You are in a stabilisation phase.
And stabilisation is inherently:
- Exploratory
- Interrupt-driven
- Non-linear
You fix one issue and uncover three more.
Trying to run this through Scrum usually leads to:
- Constant sprint failure
- Frustrated teams
- Misleading reporting
Kanban, by contrast, allows you to:
- Pull work as capacity allows
- Reprioritise instantly when risk emerges
- Maintain flow without artificial commitments
It’s simply a better fit for evolving systems under active repair.
The Hybrid Reality (What Actually Works in Practice)
Most high-performing teams don’t choose one or the other.
They separate concerns.
Scrum for Product Delivery
- Feature squads
- Clear roadmap alignment
- Sprint-based delivery
- Predictable output
Kanban for Platform, Ops, and Stabilisation
- Shared services or platform teams
- Interrupt handling
- Reliability work
- Continuous improvement
The result
- Clear expectations
- Better stakeholder communication
- More honest delivery signals
And critically, you avoid mixing fundamentally different types of work into one system.
The Leadership Mistake to Avoid
The biggest mistake is enforcing a single methodology across all teams “for consistency.”
This usually results in:
- Teams gaming the system
- Metrics that look good but mean nothing
- Delivery that still feels unpredictable
Consistency of outcomes matters.
Consistency of framework does not.
What Good Looks Like
If you’ve got this right, you’ll see:
- Product teams delivering predictably with clear commitments
- Platform teams moving quickly with visible flow
- Incidents handled without derailing delivery
- Stakeholders getting honest, understandable signals
And most importantly:
No surprises.
Final Thought
Scrum is about commitment.
Kanban is about flow.
If your environment supports commitment, Scrum is powerful.
If your environment demands adaptability, Kanban is essential.
Most organisations need both.
Very few implement either properly