Introduction
Most agility assessments put an organisation on a ladder and tell it to climb. Real organisations don't climb. They trade one good thing against another. This is about the thirteen trade-offs behind the Agility Abacus, and why the useful question is where you should sit on each one.
Most agility models assume "more agile" is always better. Real organisations work in complex, constrained environments. Sometimes what you need is more clarity, not more sprints.
The ladder we inherited
Maturity models did not start with "agile". They came out of the Software Engineering Institute at Carnegie Mellon in the late 1980s, when the US military wanted a way of telling capable software suppliers from the rest. The Capability Maturity Model, later CMMI, set out five levels from Initial to Optimising, with a simple promise attached: define your processes, institutionalise them, and capability will follow.
Underneath that promise was a belief in defined process control. Plan it in detail, document it, standardise it, and the result becomes predictable. The lightweight methods of the 1990s (RAD, Crystal, XP) and then the Agile Manifesto in 2001 were written against exactly that belief.
Then agile moved into large enterprises, and executives asked a reasonable question: how do we know it's working? From the late 2000s the answer was the agile maturity model. Readiness frameworks, practice-adoption scores, five-level radar charts. A movement that set out to escape defined process control ended up being measured with that movement's favourite instrument.
What the ladder gets wrong
In my experience, three things.
It assumes one direction.
On a ladder, higher is better. Applied to agility, that means more decentralisation, more flexibility, fewer gates and less change control, everywhere and always. Ask a Chief Risk Officer whether the core payments platform should "embrace change" more. Ask a regulated utility whether it should relax standardisation across its field operations. Sometimes the stage gate is the right answer, and a model that can only score it as immaturity is not a diagnostic. It is a sales pitch.
It turns information into a target.
Martin Fowler made the point back in 2014: the true outcome of a maturity assessment "isn't what level you are but the list of things you need to work on to improve", and "using a maturity model to say one group is better than another is a classic example of ruining an informational metric by incentivising it." I make the same argument about team velocity in the Value Management Framework: the purpose of a measure decides what it can be used for. Put "reach level 3" into a director's objectives and teams will report level 3. The ceremonies get done. Cycle times stay where they were.
It averages things that should not be averaged.
An organisation can be highly agile at team level and deeply impeded at governance level. One maturity score hides that, and then prescribes one intervention, "become more agile", for two different problems. Take a platform team that can release every fortnight, sitting behind a Change Advisory Board that meets every quarter. A maturity survey puts that team somewhere in the middle. It is not in the middle. It has two problems, in two places, owned by two different people.