Coastal Trust: a low Agilometer score that is not a 'no'

• The Agilometer is a tailoring diagnostic, not a go/no-go gate. A low score does not mean 'do not use agile'; it means 'this is where agile needs support and where PRINCE2 control should be firmer'. Its output feeds the tailor-to-the-environment principle.
• Read the profile rather than the total. Ability to work iteratively and incrementally is high, so the delivery approach itself is workable. The weak scores are about decision-making and acceptance - organisational, not technical - and those are things the project manager can influence.
• Recommendation: agile delivery inside a deliberately stronger PRINCE2 wrapper. Formal stage boundaries with evidence, a definition of done that includes clinical safety review, delegated decision-making within published tolerances, and manage by exception for anything outside them.
• Treat fixed statutory fields and audit requirements as fixed, non-negotiable requirements rather than something to 'flex'. Low flexibility there is correct and should be stated as such.
• Re-assess at each stage boundary. If decision-making and acceptance are still low at month six, that is real data for the board about organisational blockers - not a reason to abandon the approach.

Decision-making (fastest payoff)

• Replace the three committees with one decision forum with named decision-makers and published tolerances. Anything within tolerance is delegated to the product owner; the forum commits to a stated timebox, for example five working days. Anything outside tolerance escalates to the board through manage by exception.
• Publish the decision log so slow decisions become visible as a queue, not as an unexplained delay.

Acceptance

• Invite the safety officer into the loop: sprint reviews, plus a short weekly session. Show her the safety evidence produced every sprint rather than a document at the end.
• Co-write the safety elements of the definition of done with her, so it is her standard, and give her a veto at the review rather than a signature at the end.

What not to change

• The statutory fields, the audit trail and the safety approval itself. Resisting those would confirm her worst fears and destroy credibility; the argument is about how the controls are applied, not whether they exist.

• Transparency. Publish the board, the definition of done, the safety checks performed per increment and the defects found - including the bad news. Her fear is hidden work, so make the work visible. A team that hides a failed safety test to protect its velocity has broken the method, not just the relationship.
• Collaboration. Put her inside the delivery loop rather than in an approval queue: review attendance and a standing weekly session. That is a different relationship from 'submit and wait four weeks'.
• Rich communication. Use visual, face-to-face artefacts - an information radiator showing safety-critical items and the evidence attached to each - instead of a status report. Rich communication is a focus area precisely because it beats written status in high-ambiguity, high-consequence settings.
• Reframe documentation as sufficient, not exhaustive. Agile produces more usable audit evidence in most cases: review records, adherence to the definition of done, test evidence per increment, decision logs. The 200-page specification nobody reads is not the audit trail; the evidence is.
• Show, don't assert. Invite her to a sprint review in the first four weeks and let the artefacts argue.