Let’s Agile Everything
‘Beware the man of one book.’ — St. Thomas Aquinas
A friend mentioned recently that her organisation was ‘going Agile’. Every single initiative would be run under the Agile framework.
She asked what I thought and I didn’t need to say a word - she saw the answer on my face.
It is a common trap with project portfolios. A method that works well in one context gets elevated and applied everywhere, regardless of the original intent.
Agile seems to attract this more than most. We chase the initial dopamine hit of quick deliverables, forgetting that every tool has its limits.
Not a universal method
Agile is a build method originally targeted at software development. It works well for progressive delivery of well-defined independent modules, like a field service app where discrete features such as site maps, safety analyses, and customer details can be gradually added. The constrained scope, short feedback loops and fast iteration allow teams to move quickly to an outcome.
However, the same approach applied to replacing a financial management system would be a disaster.
The connections between the components, the fact there is a logical sequence of definition and development, and the need for a whole-of-system view means that rapid development of discrete modules leads to disjointed process flows and growing technical debt.
Things Agile doesn’t do well
There are three fundamental things Agile simply isn’t built to do:
Agile doesn’t question the strategy.
Once an Agile team is pointed at a problem, it becomes very good at solving that problem. It will iterate towards the best possible version of what’s in scope. What it won’t do is surface whether the problem itself is the right one to be solved. A team optimising a widget will produce the best widget it can.There is no reverse gear.
Wicked problems with divergent motivations are the definition of complexity. Taking action changes the nature of the problem itself. Agile is designed to keep moving forward: iterating, improving, progressing. But by sprint three, new information might completely invalidate your baseline. There’s no mechanism for that kind of structural rethink.It doesn’t work for bridges.
Some projects need the design completed before the build starts because the cost of change is significant. Prototyping and testing various designs before the Critical Design sign-off makes sense. Once that design is locked in, you build a plan, focus on delivery and manage any variances.
Match the nature of the Project
The point of all this is that no single approach can be applied to a portfolio of projects. Projects that thrive under an Agile approach have very specific characteristics: good boundaries, low cost of rework, and aligned motivations.
Those conditions exist mainly in software development. They exist much less often in infrastructure replacements, regulatory projects, large-scale integration work, or anything requiring tight coordination between multiple moving parts.
What Worries Me
When an organisation decides to ‘go Agile’ across the board, it’s often driven by an experience of rapid delivery on a set of projects well suited to that approach.
I have also seen it used as an excuse to avoid disciplined planning.
The appeal of a single framework is understandable because it promises a common way of working. But the cost of applying the wrong tool is often hidden, showing up only when overruns, extensive rework, and irreversible decisions become impossible to ignore.
Have you ever experienced an ineffective application of a common framework?
Would love to hear your views on this one.
