8.3 The Risk Practice in an Agile Context
Key Takeaways
- The risk practice identifies, assesses and controls uncertainty — both threats and opportunities — throughout the project.
- Agile delivery reduces risk structurally: short iterations and frequent releases convert uncertainty into evidence early and cheaply.
- Risks are identified continuously, as part of iterations, stages, retrospectives and progress reviews, rather than at scheduled risk workshops alone.
- The Agilometer is the PRINCE2 Agile technique for identifying agile adoption issues — the risk that the environment does not suit an agile approach.
- The risk register is the artifact; agile risk responses include spikes, prototypes and delivering the riskiest item first.
8.3 The Risk Practice in an Agile Context
Quick summary: The risk practice identifies, assesses and controls uncertainty — threats and opportunities — throughout the project. Agile delivery reduces delivery risk structurally by converting uncertainty into evidence early. The Agilometer identifies agile adoption issues: the risk that the environment does not suit agile working.
Purpose
The purpose of the risk practice is to identify, assess and control uncertainty during the project, so as to improve the likelihood of success.
Two things follow. Risk covers opportunities as well as threats — an uncertain event with a positive impact is still a risk, and the correct response may be to exploit it. And risk concerns things that have not happened; the moment one materialises, it becomes an issue.
How agile reduces risk structurally
This is the strongest argument for agile delivery in a governed project.
| Risk | How a sequential approach handles it | How agile delivery handles it |
|---|---|---|
| We build the wrong thing | Discovered at acceptance, after full spend | Discovered at the first release, after a fraction of spend |
| The technology will not work | Discovered during integration, late | Discovered in the first iteration that uses it |
| Users will not adopt it | Discovered after go-live | Measured after the first release, while the approach can change |
| Benefits will not materialise | Discovered in post-project benefit review | Measured release by release against the business case |
| The estimate was wrong | Discovered as cumulative slippage | Visible in velocity after two or three iterations |
The common mechanism is converting uncertainty into evidence early, when correcting the assumption is cheap. This is also why an MVP is as much a risk response as a business case technique.
Agile-specific risks
Agile delivery is not risk-free; it exchanges one risk profile for another. Risks characteristic of agile projects include:
- Scope drift. Embracing change without a disciplined benefit-ordered backlog lets the project wander from its justification.
- Insufficient user availability. The whole approach depends on a product owner and users being genuinely available. If they are not, iterations stall on unanswered questions.
- Accumulating technical debt. A weak Definition of Done under sustained delivery pressure.
- Team instability. Because throughput depends on shared context, membership churn is a direct threat to the plan.
- Governance mismatch. A board that demands fixed scope and a fixed date at the same time will get one of them plus quality failure.
- Agile adoption risk. The organization is not ready for the way of working it has committed to.
The Agilometer
The Agilometer is the PRINCE2 Agile technique for assessing how well an environment suits agile delivery, and it is the tool by which agile adoption issues are identified.
It works as a set of sliders, each rated for the project's context, covering dimensions such as:
- Flexibility on what is delivered — is there genuinely scope that can flex, or is everything a Must have?
- Level of collaboration — will customer, users and suppliers actually work together?
- Ease of communication — co-located or distributed, direct or mediated through layers?
- Ability to work iteratively and deliver incrementally — can the product be built and released in slices at all?
- Advantageous environmental conditions — does the surrounding organization support the way of working?
- Acceptance of agile — do the stakeholders, particularly senior ones, actually accept it?
A low rating is not a verdict that agile is impossible. It is a risk identified, with a response attached: improve the condition where you can, and tailor the approach where you cannot. A project scoring low on ease of communication invests in workshops and co-location; one scoring low on acceptance of agile invests in education for the project board before delivery starts.
Note the scope of the Agilometer in Version 2. It is a technique within the risk practice for identifying agile adoption issues. It is not, as it was often taught under Version 1, the organizing centre of the method, and the Version 2 Foundation syllabus does not list it among its named assessment criteria — so know what it does, and do not expect the exam to be built around it.
Artifacts and responses
Artifacts: the risk management approach (how risk will be managed, including risk appetite and tolerances) and the risk register (the record of identified risks, their assessment, responses and owners). In an agile context, risks are frequently visible on the team dashboard or project dashboard so that they are seen rather than filed.
When risks are identified: continuously. Risk identification happens as work proceeds — within iterations and across stages — and is reinforced at retrospectives and progress reviews. The capture issues and risks activity within the controlling a stage process is where uncertainties are formally logged.
Responses available include the standard PRINCE2 set — avoid, reduce, transfer, share, accept, and for opportunities exploit or enhance — plus agile-specific ones:
- Deliver the riskiest item first. Sequencing the most uncertain work early buys information when there is still time to react.
- Spikes. A timeboxed investigation whose output is knowledge rather than product.
- Prototypes and MVPs. Cheap tests of an expensive assumption.
- Short iterations. Reducing the maximum amount that can go wrong before it is detected.
- Shortening the feedback loop with users, which is a response to almost every requirement-related risk.
Which technique is used to identify agile adoption issues on a project?
A project scores very low on the Agilometer for 'acceptance of agile'. What is the correct interpretation?
A team schedules its most technically uncertain feature into the first iteration rather than the last. Which risk response does this illustrate?