Introduction
Most agility assessments place an organisation on a ladder and expect it to climb. In practice, organisations trade one useful thing against another. This article looks at the thirteen trade-offs behind the Agility Abacus and at how to decide where to sit on each.
The ladder we inherited
Maturity models, soecifically "agile 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 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.
Where the ladder is right
Some things are capabilities, and capabilities do improve in one direction. Weaker automated testing, a slower deployment pipeline or a team that abandons its practices under pressure helps nobody. For capabilities like these a progression model is useful, and the best I know is James Shore and Diana Larsen's Agile Fluency Model. Even they reject the idea that higher is always better:
"When you get on a bus, you buy a ticket for the zone that you want to reach. A zone that's further away isn't inherently more valuable; it just costs more and takes longer to get to."
The distinction I draw is: capability is a ladder; stance is a balance. How well your teams practise continuous integration is a capability. Whether pricing decisions for a savings product sit with a team or an executive committee is a stance. Maturity models treat the two alike, and much of the damage in agile transformations comes from treating questions of stance as gaps in capability.
Thirteen tensions
The Agility Abacus grew out of that distinction. Over a decade of transformation work, in agile-first and traditional enterprises, I saw the same questions of stance argued as though they were about method: agile or waterfall, SAFe or LeSS, projects or products, function or value stream. Behind each argument was a trade-off that had not been made explicit.
The Abacus sets out thirteen of these trade-offs. Each tension is a spectrum between two opposite positions, its two poles:
| Tension | What it is about |
|---|---|
| Detailed Forethought vs Adaptive Course Correction | Planning the whole piece of work in detail at the start, or planning the near term in sufficient detail and the rest in outline and revising as you learn. The first suits stable work with well-understood tasks; the second suits work where much is still unknown. It is a balance between planning for the known and adapting to the unknown. |
| Procedure Emphasis vs Result Orientation | Following defined procedures, checklists and approval routes, or setting the outcome and letting teams choose how to reach it. Procedure reduces variance, errors and regulatory exposure; result orientation leaves room to adapt and learn. One makes sure things are done right, the other that the right things are done. |
| Gatekeeping vs Enabling Flow | Requiring each stage to be completed and approved before the next begins, or removing obstacles so that work moves continuously. Gates give control and stop flawed plans going forward, but slow the response to change. Flow is faster, and needs more coordination and better tooling to stay under control. |
| Cost Focus vs Value Orientation | Judging change by cost control and financial efficiency, or by the value it creates over the longer term: returns, customer satisfaction, capability and strategic position. Cost discipline prevents overruns; value orientation keeps the reason for spending in view. Moving towards value does not mean ignoring cost. |
| Standardisation vs Flexibility | Applying the same processes, methods and templates everywhere, or adapting them to each context. Standardisation gives predictability, efficiency and easier compliance. Flexibility gives fit and room to innovate, at some cost to consistency. |
| Change Control vs Embracing Change | Routing every change to scope, schedule or budget through formal approval, or welcoming changes that add customer value and managing them through feedback and iteration. Formal control manages risk and keeps work aligned with strategy, but slows the response and discourages improvement. |
| Technical Proficiency vs Strategic Insight | Valuing deep knowledge of tools, methods and delivery mechanics, or a broader grasp of strategy, markets and stakeholder needs. Technical skill keeps work on track; strategic insight keeps it aimed at the right outcomes. Most change functions need more of the second without losing the first. |
| Centralised vs Decentralised Decision Making | Keeping decisions, including where money and people go, with a small group at the top, or giving teams the authority to decide based on their understanding of customer value. Central decisions give alignment and a portfolio-wide view. Decentralised ones are faster and closer to reality, and depend on trust, a clear strategy and decision-making skill in the teams. |
| Command & Control Reporting vs Open Information Flow | Reporting progress up the hierarchy in periodic packs shared on a need-to-know basis, or making live information visible to everyone who needs it. Formal reporting gives senior people a consolidated view, but information is lost or distorted on the way up. Open information reduces reporting effort and speeds decisions, and needs a culture where bad news is safe to share. |
| Rigid vs Adaptive Control | Holding work to a fixed plan of schedule, cost and scope, or controlling it by measuring value, customer satisfaction and the ability to respond. Fixed control suits stable conditions; adaptive control suits environments where change is constant. |
| Managing for Today vs Developing Future Capabilities | Putting resources into work that delivers near-term, lower-risk returns, or investing in the skills, processes and technology the organisation will need later. The first protects current performance; the second protects long-term resilience and growth, and carries more risk. |
| Risk Avoidance vs Embracing Uncertainty | Identifying and mitigating every foreseeable risk through registers and reviews, or accepting that uncertainty is part of complex work and building the ability to respond through experiments, short feedback loops and psychological safety. Risk avoidance prevents costly mistakes, but can slow decisions and crowd out opportunities. |
| Internal Alignment vs External Engagement | Coordinating internal resources and keeping work aligned with strategy, or engaging actively with customers, suppliers, partners and changes in the market. It is a balance between keeping the house in order and keeping in touch with the world outside. |
Both poles of every tension are legitimate, and neither is "traditional" or "agile" in any moral sense. The trouble starts when an organisation sits at one pole by design or by accident: because a previous CIO put it there, because of a regulatory finding years ago, or because it came with a consultant's framework and was never revisited. The Abacus brings these positions into view so that they can be chosen deliberately.
Balance is not the midpoint
"Balance" is easily misread as sitting in the middle of every tension. That is not what I mean, for three reasons.
First, balance moves over time. In Why change fails? I described stability as dynamic equilibrium. The right position on change control for a platform halfway through a core banking migration will be different two years after the migration.
Second, different parts of the organisation should sit in different places. McKinsey described agile organisations as "both stable and dynamic at the same time", with "stable backbone elements that evolve slowly" supporting capabilities that adapt quickly. O'Reilly and Tushman's work on ambidexterity makes a similar point about structure: running today's business and exploring tomorrow's need different designs and a deliberate way of linking them. If a payments platform and a new digital proposition team score the same on Change Control vs Embracing Change, one of them is probably in the wrong place.
Third, the tensions affect each other. Pushing decisions down to teams without opening up information flow gives people authority they cannot use well. Removing stage gates while keeping fixed schedule, cost and scope controls moves the bottleneck elsewhere. Nadler and Tushman called this congruence, and Panta Rhei uses it as a design test: do the choices reinforce or contradict one another? A balance, in this sense, is a set of positions that fit together.
The useful question, then, is where this part of the organisation should sit on each tension, given what it exists to do, and whether those positions work together.
Few of these are delivery problems alone
The Abacus began inside the Transformation Delivery Framework (TDF), and every tension shows up in delivery, because that is where the friction is felt. The causes usually lie elsewhere: in who holds decisions, in the weight of the control apparatus, in what the organisation counts as value, or in how it balances today against tomorrow. Treated purely as delivery problems, they tend to produce another round of ceremonies.
Below, all thirteen are grouped by what usually (not always) sits underneath them, with the parts of TDF, the Value Management Framework (VMF) and Panta Rhei that help.
Who decides, and on what information
Centralised vs Decentralised Decision Making; Command & Control Reporting vs Open Information Flow
These two are questions of decision rights and information flow. Panta Rhei helps you map which decisions are made where, by whom and with what authority, and distinguishes delegation, which can be withdrawn, from devolution, which is built into the structure. It also looks at where formal authority ends and informal influence begins, since empowerment that is announced but not backed by real authority changes little. On the information side, it traces where information stalls or is distorted on its way to the people making decisions. TDF's practical response is for governance forums to work from live artefacts, such as the current roadmap, finance tracker and impediment log, instead of summaries prepared a week earlier. See a worked example on how this could look like in the age of AI here.
How much control, and at what cost
Gatekeeping vs Enabling Flow; Change Control vs Embracing Change; Procedure Emphasis vs Result Orientation; Rigid vs Adaptive Control
These four concern the control apparatus as a whole. Each board, committee, working-group and procedure was justified when it was introduced, but the total burden is rarely added up. Panta Rhei maps every formal control activity, with its inputs, outputs, frequency and decision rights, and asks of each whether it provides insight a decision can rest on or only the appearance of assurance. VMF adds a question for governance forums: are they reviewing status (RAG ratings, milestones, spend) or evidence of value? For controls based on measures, VMF's test is whether anyone would decide differently if a metric moved by 20%. TDF separates activity metrics, which show that people are busy, from flow metrics such as lead time, cycle time and queue depth, which show whether value is moving.
What counts as value, and as risk
Cost Focus vs Value Orientation; Risk Avoidance vs Embracing Uncertainty
These depend on what the organisation means by value, and that is often not agreed: strategy talks about impact, delivery about benefits and finance about returns. VMF starts by agreeing the terms. Where value dimensions conflict, such as cost against customer experience or speed against compliance, it sets explicit trade-off rules so that the outcome is not left to seniority or politics. On risk, most organisations track delivery risk thoroughly and risk to value hardly at all, so a programme can report green while the case for it falls apart. VMF brings risks to value, such as adoption, attribution and timing, into the same conversation.
Today and tomorrow
Managing for Today vs Developing Future Capabilities; Technical Proficiency vs Strategic Insight
These are about time horizons and line of sight. When all value is treated as arriving on one timeline, quick wins crowd out longer-term investment. VMF tags initiatives by horizon and sets target ratios for each. Panta Rhei asks every unit to state whether it is designed to exploit, to explore or both, and builds the capacity for continuing change into the operating model, so the organisation does not depend on one transformation programme after another. For technical proficiency and strategic insight, VMF makes the line from strategic objective to delivered work explicit, so technical teams can see what their work is for, and TDF puts technical quality on the governance agenda before it turns into a remediation programme.
How the organisation meets its context
Detailed Forethought vs Adaptive Course Correction; Standardisation vs Flexibility; Internal Alignment vs External Engagement
These three are about fit with circumstances. TDF's position is that defined ways of working suit work where clarity is very high, and adaptive, iterative ways suit the rest; it connects the planning layers, from the multi-year plan down to the sprint, so that detail is added where clarity allows. Panta Rhei treats standardisation and mutual adjustment as design choices to be made unit by unit. For external engagement, TDF makes scanning of regulatory, market and technology change a recurring input to planning, and VMF asks whose view of value each piece of work is serving.
Panta Rhei asks one further question before any of this: is the impediment structural, a matter of meaning, or political? If decisions stay at the top because an executive's standing depends on holding them, mapping decision rights will not move them. The politics has to be dealt with first.
How far to move, and where to start
Deciding where you want to sit is half the work. The other half is judging how far you can move from where you are. Panta Rhei calls this the Adjacent Possible: the most ambitious next state the organisation can actually absorb. Many transitions fail because the distance was too great, even when the destination was right. For this reason the Abacus asks for your current and desired position on each tension and does not produce a score. The gap between the two is a choice to examine. A large desired shift on five tensions at once should be treated as a warning, however bold it looks in a strategy deck.
In practice:
- Start with few (~5) tensions that most impede the flow of value, and leave the rest for now.
- Choose patterns that address the specific impediment, instead of adopting a method as a package.
- Reassess after each transition state, because what is achievable changes as you move.
- Keep the results with the people who have to act on them, and out of performance objectives and league tables.
- Record the tension, the pattern used and the result, so that the organisation gets better at transformation over time.
Using the Abacus
The Abacus is meant to start conversations. You can use it:
- as an executive team, to find out where you disagree about your current and desired positions, which is often the most useful result;
- as a facilitation aid for strategy or transformation planning;
- as a starting point for deeper diagnosis with the Transformation Canvas and Panta Rhei flow mapping.
Which level, of what?
An executive asked to reach "level 4" rarely needs level 4. What they need is to decide, platform by platform, how much change control the organisation can give up, how much it must keep, and who owns that decision. That conversation is harder than agreeing a board-pack target, and more likely to change how the organisation works.
Agility isn't one-size-fits-all. The Abacus helps you make that explicit.
Apply this to your organisation → Agility Abacus
If you are an executive being asked to "reach the next level", send me a message. I can help you work out which level, of what, and whether you need it at all.