Agile Truths and Fallacies

“Becoming agile is essential“

Presented as critical in responding to the challenges of today’s complex environment – sometimes even as the answer – something along this lines is an increasingly familiar refrain and rallying cry.

Whether it’s from consultants like PwC, Deloitte, McKinsey or as seen in lists of corporate strategic priorities, “agile” is seen as a big deal.

And, in a sense, we’d agree: how you do things is very important, and the complexity that defines and dominates today’s challenges indeed requires that you:

Have more flexible structures.
Focus more on collaboration between teams.
Rely less on formal instruments (contracts, etc).
Iterate, learn and adapt fast.

These are all cornerstones of agile approaches.

And yet purveyors of the “becoming agile is essential” message almost always fall into one or both of two fatal fallacies.

Fallacy #1: Agile Solves Complexity

The first fallacy is that agile is a way to control – or even overcome – Complexity.

Here, agile is ultimately seen as a way of taming or negating the dynamics of Complexity – a distinct alternative to the more familiar command-and-control ways of operating, but one that eventually achieves similar ends.

So, whilst tightly-defined contract clauses, risk management processes and organisational roles may be out, the aim is still ultimately to eliminate unknowns, break situations into their constituent parts, bring control, manage the situation, and thereby achieve largely predetermined objectives.

However, this betrays a fundamental misunderstanding of Complexity.

Complexity can – and should – be understood, but at the level of its principles and not in terms of “solving” specific situations; complexity can (and should) be guided and harnessed, but it can never be controlled or “overcome”.

Go into agile as a “back door” to “taming” or “getting round” reality and your underlying assumptions won’t have changed, you’ll have missed the point, and you’ll fail to benefit from agile methods to any meaningful extent.

Fallacy #2: Agile Is An End In And Of Itself

The second fallacy is to “deploy agile” as a way of doing things without properly reconsidering what those things are in the first place.

Most obviously, whilst you can be more effective at doing things, that’s of no benefit at all if they’re the “wrong” things.

More subtly, though, people seem to assume that the way you do things has more bearing on what those things are – especially their outcomes – than the other way round.

Of course, if asked directly, nobody would say that it’s not important what you are doing.

However, ways of working – “agile”, “innovation”, “going digital”, “collaborative behaviour”, etc – are nevertheless (even if unconsciously) mistakenly seen as things that can be changed directly, which will then in turn transform results.

We’re therefore back in similar territory to our first fallacy – that you can control and change reality – and we see a confused mess of conflating means with ends, and almost exclusively prioritising means.

After all, whilst the means – the ways in which we operate – are clearly important, a true understanding of complexity shows that how we operate emerges principally from (and is ultimately constrained by) what we are focused-on; not the other way round.

So, you can try and implement agile to change the situation, but if what you ultimately value – your Things That Matter – are things like efficiency, controlling costs, adhering to schedules, etc, agile will largely “bounce off”.

You might see some incremental benefits, and it might be more “fun” for a time for those involved, but approach and focus will eventually start pulling against each other.

And if we look at typical lists of corporate priorities – ultimately “what” they are trying to do – what do we find?

Digitalisation and AI
Attracting and retaining talent
Training
Continuous improvement
Resilience
ESG
etc

All important things, but ultimately “conventional” priorities around control, order and ways of doing things; very little – even nothing – about what is being done, which ought to be serving the end customer in helping them realise value.

True Agility: Value Management

So, over to you.

You can of course choose to just “go agile”, hoping that things will somehow improve – you’ll almost certainly make a lot of consultants considerably richer in the process, but you’ll almost certainly be ultimately disappointed.

Or, before you can focus on agility and use it effectively, you can instead:

Understand complexity and the nature of value.
Get to grips with what you and your end customers value.
Articulate and focus on the Things That Matter.

You’ll then have something to “be agile” about – not just as an end in and of itself – and it then truly can be part of transformation: agility in service of Value Management, properly focused-on and harnessed-by the Things That Matter.