The Agilometer survived Version 2. It is the most under-used instrument in the method

Almost everything distinctive about PRINCE2 Agile Version 1 has dropped out of the Version 2 syllabi. Fix and flex, the hexagon, the five targets — none of them appear in either the Foundation or Practitioner syllabus, and none appear in the independent accredited course material I have checked.

One thing survived. The Agilometer is in the Version 2 Practitioner syllabus, and I think it is the most valuable and least used instrument in the entire method.

It is six sliders, each rated one to five, and it answers a question that nobody asks before starting an agile project: how much agility can this environment actually absorb?

The six sliders

From AXELOS’s own description of the tool:

1. Acceptance of agile
2. Advantageous environmental conditions
3. Ability to work iteratively and deliver incrementally
4. Ease of communication
5. Level of collaboration
6. Flexibility on what is delivered

Rate each from one — lowest — to five. The output is not a score to be totalled and compared against a threshold. It is a shape, and the shape tells you where you will get hurt.

I want to make a case for using it that has nothing to do with passing an exam.

Why the low sliders matter more than the average

Most maturity instruments are used to produce an average, and the average is then reported as a number that goes up over time. The Agilometer is more useful the other way round. Find the lowest slider and design around it, because a single one on a critical dimension will defeat high scores everywhere else.

Take slider six, flexibility on what is delivered. If your project’s scope is fixed by a regulation, a contractual commitment or a statutory deadline, that slider is a one or a two, no matter how enthusiastic the team is. You can still work iteratively — you should — but you cannot flex scope, which means the whole prioritisation apparatus of agile has nothing to work on. Your iterations will be about sequencing and risk retirement, not about deciding what to drop. Anyone who plans that project as though scope will flex is planning a project that cannot be delivered on time.

Or slider four, ease of communication. Distributed teams across time zones, a customer available two hours a week, an operations function that will not release a subject matter expert. Score it honestly at two, and the design consequence is obvious: you need far more written specification than a co-located team would, and pretending otherwise in the name of “working software over comprehensive documentation” is how requirements get discovered at user acceptance testing.

The instrument works because it forces the conversation to happen before the delivery approach is chosen, rather than in the retrospective after the third failed sprint.

The honest failure mode

Every readiness assessment has the same weakness, and I will state it rather than let a reader discover it: the person running the assessment usually knows what answer is wanted.

An organisation that has publicly committed to an agile transformation will produce Agilometer scores of four and five, because the sponsor is in the room and nobody wants to be the person who says the environment is not ready. That is not a flaw in the tool. It is a flaw in who is holding it.

Two things fix it. Score it anonymously, by several people who work in different parts of the delivery chain, and look at the spread rather than the mean — a dimension where the team says two and the sponsor says five is more informative than any average. And require the assessment to be repeated at each stage boundary, so that a score which was optimistic at initiation becomes visible as a variance later.

When nobody asks the question: i6

There is one official audit report I return to more than any other, because it is the rare case where a public auditor names the delivery method as a causal factor, quantifies the settlement, and shows external assurance rating a programme green while it was dying.

In June 2013, the Scottish Police Authority signed a fixed-price ten-year contract worth £46.11 million with Accenture for i6 — a single national system replacing around 130 legacy systems and covering roughly 80 per cent of core policing activity across six functional areas: crime recording, criminal justice, custody, missing persons, vulnerable persons and property.

Expected efficiency savings were £200 million over ten years.

The delivery approach was waterfall. Audit Scotland is unusually explicit about what that meant in practice: “Once a phase is complete, the process moves on to the next phase and there is no turning back.” Police Scotland could not test the system until late in development. The report notes that agile approaches were gaining currency at the time but were not selected — and links that choice directly to the late discovery of critical defects. Fundamental flaws surfaced in testing in August 2015, more than two years into a contract signed in 2013.

The premise that was wrong from the start

The bid was predicated on reusing an existing Accenture product. Audit Scotland’s finding: “The belief that most of the i6 system could be based on an existing IT system proved incorrect.” Accenture “had underestimated the complexity of the system and had, at contract stage, overstated its own ability to deliver.”

Look at that through the Agilometer. Slider three — ability to work iteratively and deliver incrementally — was low, because a monolithic replacement of 130 systems across six functional areas does not decompose easily and the contract had not been written to allow it to. Slider six — flexibility on what is delivered — was low, because the scope was fixed by a fixed-price contract with a stated savings target. Slider two — advantageous environmental conditions — was low, because Police Scotland itself was in the middle of a national force merger.

None of that was hidden. All of it was knowable in 2013.

Eighteen months of dialogue that produced no shared understanding

This is the finding I find most sobering, because it is the one most organisations believe they are immune to.

There were eighteen months of competitive dialogue and 160 discussion sessions before contract. And still: “Within weeks of starting work, there were disagreements between Police Scotland and Accenture” over interpretation and scope. A contract variation in April 2014 tried to close the gaps.

A hundred and sixty sessions. Weeks to disagreement.

If eighteen months of structured dialogue cannot produce a shared understanding of requirements, the problem is not the amount of specification. It is that written requirements are an inherently lossy medium for complex operational work, and the only reliable way to discover the loss is to build something small and look at it together. That is the whole argument for incremental delivery, made by a public auditor without using the word agile.

Assurance rated it green

Scottish Government Gateway reviews, healthchecks and ICT technical assurance reviews continued rating delivery confidence amber or green while the programme board’s own concerns escalated.

I would put that sentence in front of every audit committee I sit with. External, independent, professional assurance — the kind organisations pay for precisely so that somebody outside the programme will tell the truth — rated a programme green while the people inside it knew it was failing.

Assurance is only as good as what it examines. A review that inspects governance artefacts, plan documents and RAG reports will find them present and correct, because producing them is what a programme office is good at. A review that asks show me the working software and let me watch a police officer use it would have reached a different conclusion in 2014.

And the governance response made it worse

When the relationship deteriorated, the programme board — chaired by the Deputy Chief Constable, with the SPA, Police Scotland ICT and the Scottish Government’s CTO — moved to closed sessions excluding Accenture.

Audit Scotland records this as a governance failure in its own right. It damaged the working relationship at exactly the point where the two parties most needed to solve a shared problem.

I understand the instinct. A board that suspects it is being managed by its supplier wants a room without the supplier in it. But the effect is to convert a delivery problem into a contractual dispute, and contractual disputes do not produce software.

The outcome

The contract was terminated in July 2016. Accenture refunded £11.09 million of payments and paid a further £13.56 million for staff and capital costs — a total settlement of £24.65 million. The estimated cost to complete had it continued was described only as “many millions more.”

Three years. Nothing delivered. £200 million of expected savings never realised.

Audit Scotland’s conclusion resists the tidy explanation: “There is no single reason why it failed.”

The Auditor General, Caroline Gardner, framed it forward: “Given the role that i6 was to play in police reform, there is an urgent need for a frank assessment of Police Scotland’s IT requirements.”

Using the Agilometer for real

Six practical rules, from having run this exercise more times than I would like to admit.

Score it before you choose the approach, not after. The Agilometer is an input to the delivery strategy. Once the strategy is announced, the scores become a justification exercise.

Score it anonymously and separately. Delivery team, business stakeholders, supplier, sponsor. Compare the spread. A four-point gap between the sponsor and the team on “acceptance of agile” is the single most predictive thing you will learn all quarter.

Design around the lowest slider, do not average it away. Low flexibility on scope means your iterations buy risk reduction, not scope reduction. Low ease of communication means more written specification, not less. Say so in the delivery strategy.

Turn low scores into named actions with owners. “Acceptance of agile: 2” is not a finding. “Acceptance of agile: 2 — the operations directorate has not agreed to release subject matter experts; Executive to resolve by 30 April, otherwise we plan on a specification-led basis” is a finding.

Re-score at every stage boundary. Environments change. A programme that starts at three and drifts to two has a governance problem that no burndown chart will show.

And be willing to conclude that the answer is not agile. PRINCE2’s seventh principle is tailor to suit the project. Tailoring includes tailoring towards more structure, not only towards less. An environment with fixed scope, weak communication and low collaboration is not a failure of ambition; it is a set of conditions, and pretending otherwise is how you get an i6.

The thing the tool actually does

Nobody has ever thanked me for an Agilometer assessment at the time. It is a slow, awkward conversation that produces low numbers and makes a sponsor defensive.

What it does is convert an assumption into a written statement that somebody has to disagree with in the room. In 2013, somebody would have had to look at slider three, look at a single national system replacing 130 others under a fixed-price contract, and say out loud: we believe this can be delivered incrementally.

That sentence is much harder to say than it is to assume.

A worked example

Abstraction makes this sound easier than it is, so here is what a real scoring conversation produces. This is a composite of assessments I have run, not a specific client, and the numbers are illustrative — but the shape is one I have seen many times.

A mid-sized financial services firm, replacing a customer onboarding platform. Regulatory deadline fixed. Vendor product with configuration rather than bespoke build. Business subject matter experts fully committed to business-as-usual.

Three things fall out immediately, and none of them would have come from an average.

The sponsor is two points higher than everyone else on almost every dimension. That gap is the finding. It is not that the sponsor is wrong; it is that the sponsor is describing an intention while the other two groups are describing an experience. Any delivery strategy built on the sponsor’s row will fail, and the failure will be blamed on the team.

Flexibility on what is delivered is a one from the people who define the scope. A regulatory deadline with a prescribed outcome means scope genuinely cannot flex. So iterations must buy something other than scope reduction — early integration risk, regulatory interpretation, data quality. Say that in the delivery strategy explicitly, or the first sprint review will be an argument about why nothing was dropped.

Ease of communication is a two from two of three groups. The subject matter experts are not available. That is not a cultural problem, it is a resourcing decision made elsewhere, and it will not be fixed by a stand-up. It converts into a named action for the sponsor with a date, and if it is not resolved the delivery approach must change to compensate — more written specification, longer iterations, explicit assumption logs.

The output of an Agilometer session should be about six sentences long. Not a dashboard. Six sentences that a project board has to either accept or argue with.

Sources

• PeopleCert, PRINCE2 Agile Practitioner (Version 2) syllabus, v2.0 (May 2025) — Agilometer retained — peoplecert.jp
• Allan Thomson, AXELOS, Assessing the agile factor with PRINCE2 Agile’s Agilometer (24 September 2019) — the six sliders — wired-gov.net
• Audit Scotland, i6: An update on the Police Scotland i6 programme (March 2017) — audit-scotland.gov.uk
• PeopleCert, PRINCE2 Agile Foundation (Version 2) syllabus, v2.0 (May 2025) — peoplecert.jp