Risk Governance in Agile Delivery

The Agile Risk Paradox

Agile teams often resist formal risk management because it feels "waterfall." But enterprise environments need governance. The solution isn't to choose one or the other — it's to make risk management lightweight, continuous, and embedded in your existing ceremonies.

The Risk Framework

Risk Identification — Make It Continuous

Don't wait for a quarterly risk workshop. Surface risks in every ceremony:

• Sprint Planning: "What could prevent us from meeting this sprint goal?"
• Daily Standup: "What's blocking me?" (blockers are risks that materialised)
• Sprint Review: "What surprised us this sprint?"
• Retrospective: "What nearly went wrong?"

Risk Assessment — Keep It Simple

Use a 3x3 matrix (not 5x5 — that's false precision):

| | Low Impact | Medium Impact | High Impact | |---|---|---|---| | High Probability | Medium (4) | High (6) | Critical (9) | | Medium Probability | Low (2) | Medium (4) | High (6) | | Low Probability | Low (1) | Low (2) | Medium (3) |

Score = Probability × Impact. Anything scoring 6+ needs active mitigation.

Risk Response — Four Options

For every risk, choose one:

1. Mitigate: Take action to reduce probability or impact 2. Accept: Acknowledge it and monitor (for low-scoring risks) 3. Transfer: Move the risk to someone better positioned to manage it (insurance, vendor SLA) 4. Avoid: Change the plan to eliminate the risk entirely

Risk Monitoring — The Weekly Rhythm

Every week, in your programme sync:

• Review top 5 risks by score
• Update probability and impact (has anything changed?)
• Check mitigation actions are progressing
• Identify new risks surfaced this week
• Close risks that are no longer relevant

Time required: 10 minutes per week. That's it.

The RAID Log in Practice

RAID = Risks, Assumptions, Issues, Decisions

Risks vs Issues

• Risk: Something that MIGHT happen in the future
• Issue: Something that HAS happened and needs resolution now

When a risk materialises, it becomes an issue. Move it from the Risks tab to the Issues tab.

Assumptions

Every plan is built on assumptions. Document them:

• "We assume the API team will deliver by Sprint 5"
• "We assume the budget won't be cut mid-programme"
• "We assume the vendor will meet their SLA"

Review assumptions monthly. When one proves wrong, it usually creates a risk or issue.

Decisions

Document every significant decision:

• What was decided
• Who decided it
• Why (rationale)
• What alternatives were rejected
• When to review the decision

This prevents revisiting decisions and provides audit trail.

Governance Without Bureaucracy

The 80/20 Rule for Risk

• 80% of your risk exposure comes from 20% of your risks
• Focus governance energy on the top 5 risks, not all 50
• Review the full register monthly, but manage the top 5 weekly

Lightweight Risk Ceremonies

| Ceremony | Frequency | Duration | Focus | |----------|-----------|----------|-------| | Risk identification | Every sprint | 5 min (in planning) | New risks | | Top 5 review | Weekly | 10 min (in sync) | Active mitigation | | Full RAID review | Monthly | 30 min | Complete register | | Risk workshop | Quarterly | 2 hours | Strategic risks |

Escalation Triggers

Escalate a risk when:

• Score increases to 6+ (Critical/High)
• Mitigation action is overdue by 2+ weeks
• Risk owner is unable to mitigate alone
• Risk impacts multiple teams or programmes

Common Mistakes

1. Risk register as a document, not a tool — if nobody looks at it weekly, it's useless 2. Too many risks tracked — focus on top 10-15, archive the rest 3. No owners — "the team" is not an owner. Name a person. 4. Mitigation without deadlines — "monitor the situation" is not a mitigation plan 5. Only identifying technical risks — people risks, commercial risks, and organisational risks are often bigger

---

Download the [Programme RAID Register template](/templates) with built-in scoring, ownership tracking, and dashboard summary.