‘Wagile’: the cost of changing the method but not the mindset
Why so many Agile adoptions stall halfway, and what it actually takes to finish the job.
The story is familiar. A team decides to go Agile, the intent is good; they want to move faster, respond to change, get out of the slow grind of stage-gate delivery. They do the training, stand up a board, agree a sprint cadence, and begin. For a while, it feels like progress.
Then they meet the organisation around them, and the organisation has not moved. Sign-offs still travel through the same committees, budgets are still set once a year, senior stakeholders still expect locked-down deliverables and a steering report. The team is running Agile inside a business that is still running Waterfall, and the two quietly begin to grind against each other.
We call this ‘Wagile’. Not a design choice, but a symptom. The predictable result of changing what a team does without changing the system it works inside.
How to spot ‘Wagile’
You can see the cost most clearly in one person. Watch the most capable member of the team, the one who saw that something needed to change and had the courage to try. Six months in, they are spending their days as a translator turning sprint outputs into stage-gate language and iterative learning into the annual plan the business actually runs on. They are not delivering change anymore, they are absorbing the friction between two systems no one reconciled. This is the compressed compensating mechanism in its clearest form, a good person holding the gap together through personal effort because nobody above them has redesigned it away.
Here is what makes ‘Wagile’ so stubborn. It is not a process problem, it is a problem of what people are rewarded for believing.
Waterfall assumes you can know the answer up front, that the plan will hold, and that progress means completing the stages you signed up to. Agile assumes the reverse, requirements will move and early learning beats early certainty. Changing course is a sign of intelligence, not failure. A team can put the second belief on the wall, but if the system around them still runs on the first, still reading a changed plan as a slip and still asking "why are we behind the baseline" rather than "what did we learn", the team works out the real rules quickly. They keep the sprint board because they were told to. They keep the Waterfall caution because that is what gets them through the next review intact. Capable people default to safety, and in most organisations safety is still Waterfall.
The real gap is not between two methodologies, but between the behaviour a team is asked to adopt, and the behaviour the system around them models and rewards.
None of this means the method was the wrong choice. The effort that goes into an Agile adoption is real, and usually the right instinct. The method is simply not the thing that carries the change. Waterfall, Agile, ‘Wagile’, none of it delivers transformation on its own. What delivers transformation is a set of conditions, and they hold true whatever the method written on the board.
So, what actually drives the change?
A small number of priorities, protected when pressure increases, rather than allowed to multiply until everything is urgent, leaders who sponsor the change by redesigning how decisions get made, not by endorsing it at the kick-off and reappearing at the review, governance that decides and clears blockers instead of just monitoring, decision rights that match how the work really flows, middle managers, given clarity and the agency to act, and people who have moved from doing what they are told, to understanding why it matters, to caring whether it works. This is how the shifts survive a difficult quarter.
Get those conditions right and the method is close to a detail. Get them wrong and even a well-run framework returns to type the moment attention moves elsewhere.
The honest question
So if your transformation feels off, delivery still slow, teams still frustrated, the governance overhead no lighter than the day you started, the question is not whether you are doing Agile properly, it is a harder and more honest one; when someone on your team needs to change the plan, does the organisation around them make that easy, or does it make it risky?
The answer is rarely a clean yes; it’s usually a list of reasons the system cannot quite move, each of them reasonable, none of them the real one. Sitting with that answer is uncomfortable, and most organisations would rather adjust the method again than face it. More than any framework, this is what decides whether the change will last.
This is the work we do at Egremont. Not the method, but the condition underneath - the clarity, the operating model, the leadership behaviour and the governance that let a new way of working actually take hold. We work side by side, not for. Because the change that holds is the change you can sustain yourself.