Stop Implementing Agile. Start Fixing Delivery.
Agile is a sign that delivery is broken and a sign that problems will continue. Kanban and evolutionary change address delivery issues directly rather than putting faith or investing in Agile frameworks or models.
Agile is a solution implemented by organizations that can’t deliver.
When delivery is broken, the organization reaches for a process. Agile becomes the promised fix: adopt the framework, run the ceremonies, stand up the teams, and delivery will follow. It rarely does. The problems that block delivery are vast, varied, and complex. No process can solve them. Implementing a process is not the same as addressing the real problems. The problems stay exactly where they were, now with a transformation on top of them.
Going Agile is the easier option. Implementing Scrum, forcing teams into sprints, hiring Scrum Masters and Agile coaches — none of it requires engaging with the delivery challenges. The practices are promises, not solutions. When delivery is slow, creating a backlog, prioritizing tickets, and standing up new teams feels like progress. It isn’t. None of it makes up for poor delivery. At some point, you still have to fix the problems.
Agile is a sign that delivery is broken, and a sign that problems will continue. If your organization is doing corporate, framework driven Agile, delivery is probably bad and probably not getting any better. The Kanban method is the way out: start with what you do now and improve it through evolutionary change.
What Actually Improves Delivery
The only thing that improves delivery is fixing the problems.
One approach starts there: Kanban evolutionary change. Map the value streams. Map the team and management structures. Understand how work actually flows. Know your customers. Know your services. Then improve what is already there.
It doesn’t tell you the way you work is wrong. It doesn’t ask you to replace your method with a new one. It starts with what you do now and helps you get better, however good or bad the starting point is.
That’s the only place you can start from. Not a target operating model. Not a framework rollout. The system you already have, made better.
Agile Gets the Blame
When Agile is implemented without its core principles and values, delivery doesn’t improve, and Agile gets the blame.
The blame is misdirected, but understandable. Agile transformations are disruptive and carry a notorious reputation. They disrupt the organization. People leave. Delivery still doesn’t improve. Lots of activity, little progress. When the results don’t show up, the framework takes the blame for a system it never touched.
The more focus there is on “Agile,” the bigger the tell that the organization can’t deliver.
The Feedback-Loop Test
Evolutionary change (Kanban) enables and supports continuous improvement and learning. You take the current process, mutate it a bit because it wasn’t fit for purpose, evaluate whether it got better, then keep going. The loop is the point. The test: what does the approach learn, and how does that learning change it? If nothing learns anything, nothing is changing. You’re just moving things around.
Implementing Framework agile is a longer, more expensive and more disruptive bet. It aims at creating a target state of practices — stand-ups, sprints, story points, ceremonies — and hopes that if those practices are correctly implemented by people with the correct skills and mindsets, then delivery will improve.
| Evolutionary change (Kanban) | Framework Agile | |
|---|---|---|
| What you implement | Fixes to delivery problems — smaller batches, fewer handoffs | Framework practices — stand-ups, sprints, story points |
| What you measure | Service delivery — lead time, throughput, release frequency | Practice adoption — velocity, ceremony count, maturity scores |
| Where you start | What you do now | A target operating model |
| Overhead | Almost nothing — a board, a cadence, the people already doing the work | New roles, practices, ceremonies, artifacts — Scrum Masters, Agile Coaches, estimation meetings |
| Who designs it | The doers are the designers — the team changes its own workflow | Consultants — an external team designs the future state |
| How it’s introduced | With people — pulled, not pushed | Forced on people — a mandate, a rollout plan |
| When the consultants leave | The change holds — the team owns it | It falls apart — the coaches have to come back |
| When it fails | Safe to fail, roll back, learn — a change that didn’t help gets reverted | Blame the framework, reorganize — the change agent gets fired, the org restructures |
The left column highlights Kanban’s emphasis on feedback loops, continuous improvement and evolutionary change. The right column describes a rollout: install the practices and measure adoption.
Kanban creates the conditions for things to improve without controlling how.
Measure the Effect of Agile
How do you measure evolutionary change? You don’t do it by measuring process adoption. Adoption metrics are compliance metrics, they tell you how much of the framework was installed, not whether anything got better.
But the goal of an Agile transformation is not the adoption of Agile practices, it’s the effect they have. How much better are customers being served? Are teams able to delivery faster? Every team and value stream should be equipped to track lean metrics including:
- Customer lead time — from commitment to delivery
- System lead time — from pull to delivery
- Throughput
- Predictability
- Release frequency
- Customer satisfaction
These aren’t an alternative set of metrics. They’re the real and true measures of agile delivery.
The goal is improved service delivery, not “doing more Agile practices.”
Change Can’t Be Forced
Evolutionary change can’t be forced. Brute-forcing people into a new way of working holds for a while, but when management attention shifts elsewhere, people fall back to old ways of working.
Nobody wants to be told how to work.
Effective evolutionary change isn’t done to people; it’s done with people. Only the doers really know how a system is working and what the challenges are. That’s why evolutationary approaches to change don’t need management consultants or lots of managers. There’s no distinction between process designers and process doers. The doers are the designers.
Low Overhead, but Harder in the Ways That Matter
Evolutionary change costs almost nothing:
- It doesn’t need big training programs.
- It doesn’t need Scrum Masters or Agile coaches.
- There are no new roles, ceremonies, estimation, or artifacts to learn.
Instead of up front costs, evolutionary change requires more time to be spent on problem-solving, continuous improvement, and developing and implementing solutions to delivery problems.
Evolutionary change is harder than framework-Agile in some ways, because you have to get the important stuff right.
Delivery won’t improve if people only change what they do, or how they think in isolation. Everything that affects the value stream has to be on the table. Delivery teams, platforms, dependencies, partners, stakeholders, finance, and sharedservice providers are all connected.
It makes no sense to force an agile transformation if teams don’t have the people or skills they need. Delivery won’t improve if teams are set up in ways to maximize silos and dependencies. Teams can’t go faster if modern DevOps practices don’t support them. Everyone needs to be in the room.
No Marketing Magic
There’s no marketing magic behind evolutionary change. It’s a radical alternative to corporate Agile, focused on fixing the problems and making things better. There’s no endpoint, no day the consultants send their invoice and declare you agile. You just keep evolving.
The only magic behind evolutionary change is that it’s the only thing that works. Everything else is activity without progress.
Malcolm Bastien
Enterprise Agile Coach
Enterprise Agile Coach helping leaders in Fintech, Banking, and HealthTech build fast flow through systems thinking and aligned autonomy, empowering teams to deliver high-performance results at scale.