Somewhere in most struggling transformation programmes, someone suggests: "Maybe we need to be more agile about this." A framework gets rolled out: Scrum ceremonies, sprint boards, a SAFe certification for the leadership team, often brought in through the same agile consulting firms that handle framework rollouts elsewhere in the business. Three months later, adoption is still the problem. It just has new vocabulary now.
Here's why that keeps happening, and what actually fixes it.
Agile Was Built to Solve a Different Problem
Agile frameworks were designed to help teams build software more responsively, with shorter cycles, faster feedback, and less rigid planning. That's a genuinely useful problem to solve, and one many technical teams benefit from. It's also the problem most agile consulting is built to address.
But transformation adoption isn't a build problem. It's a people problem. The technology can be delivered flawlessly and still sit unused six months later because the people meant to adopt it were never brought along, their workflows weren't considered, their concerns weren't heard, or the change was announced rather than embedded.
A sprint board doesn't fix that. It wasn't designed to.
The Pattern We See Repeatedly
Digital transformation doesn't fail in IT. It fails in the middle, in the gap between a system going live and people actually changing how they work. Adding an agile framework on top of a struggling rollout often adds process overhead to a problem that was never about process.
Teams end up running retrospectives about why adoption is slow, without addressing the actual causes: unclear ownership, insufficient training, or a workforce that was never genuinely consulted before the change was decided.
What Actually Drives Adoption
Change adoption is its own discipline, separate from delivery methodology or agile consulting. It typically requires:
- Embedded change leadership inside the teams affected, not just communications sent to them
- Direct engagement with resistance, rather than assuming it will fade once training is complete
- A defined embed period, usually 3–9 months, long enough for new behaviour to become habit, not just policy
- Leadership visibly using the new way of working, not just mandating it
None of this is about which ceremonies your teams run. It's about whether the people affected by the change trust it enough to actually use it.
When Agile and Change Adoption Work Together
To be clear, this isn't an argument against agile methodology, or against agile consulting as a discipline. Teams building or iterating on a product often benefit genuinely from agile ways of working. The point is narrower: a framework is not a substitute for change leadership, and conflating the two is how transformation programmes quietly stall while everyone involved believes they're doing the right thing.
Frequently Asked Questions
Can agile frameworks help with change adoption at all? They can support communication and iteration once change leadership is already in place, but they're not a substitute for it. Adoption is driven by trust and embedded support, not ceremony cadence.
How do I know if our transformation problem is methodology or adoption? If the technology works but people aren't using it, or are working around it, that's an adoption problem, not a delivery or framework problem. The fix looks completely different.
Should we bring in agile consulting to fix a stalled transformation? Only if the actual gap is methodology. If people already understand how to use the new system and simply aren't, agile consulting will add process without addressing why adoption stalled in the first place.
The First Conversation Is Always Free
If your transformation has the right technology but adoption still isn't landing, we provide one day of senior practitioner time, free, no obligation.
Book Your Free Project Assessment.
