I know Agile methodologies can be frustrating for some folks, but you really can’t beat the short iterations and empirical evidence for proving delivery of value. Is it somewhat risky because you’re not calling out every key program milestone like you do in Waterfall? Yes. Is it possible to have horrible scope creep? Yes. Can you be sure you’re not wasting 18 months after 2? Absolutely. Agile only pays off if you can actually see what’s helping or hurting delivery.
That only works, though, if you’re honest about what’s really happening inside the work. For me, that honesty lives in a simple tool: a living RAID log.
As a PM/PO working with Agile, I think you should keep a constantly updated RAID log in Confluence or whatever system your team actually uses. Not a dusty artifact you fill out for a steering deck and never look at again, but a working object you interrogate every sprint. In Scrum, it’s even better to walk it right before (or during) the Sprint Retrospective, when the team is already in an inspect-and-adapt mindset.
RAID is basic on paper:
Risks / Assumptions / Issues / Dependencies.
But when it’s alive, it becomes the connective tissue between strategy, teams, and reality. It’s where you see the early warning lights, name your bets, expose the uncomfortable truths, and make decisions you can defend later.
Most teams say they’re “managing risk.” A living RAID log is where you prove it.
Confluence Ready RAID Template
1. Set up the RAID log
Create a simple table with columns like:Type | Item | Description | Owner | Due / Review Date | Status
2. Ask RAID questions as a team
R – Risks (might happen)
- What could stop us from hitting the next Sprint Goal?
- Where do we feel “uneasy” but haven’t written it down yet?
- What’s fragile if one person leaves, gets sick, or is pulled to another project?
A – Assumptions (we’re treating as true)
- What are we assuming about scope, dates, or capacity that isn’t guaranteed?
- What are we assuming other teams will deliver, and when?
- If this assumption is wrong, what breaks first?
I – Issues (already happening)
- What is slowing us down right now?
- Where are we reworking the same thing twice?
- What’s blocking progress that nobody “owns” yet?
D – Dependencies (outside our direct control)
- Who are we waiting on, and for what?
- Who is waiting on us, and do they know when we’ll deliver?
- Which dependencies are tied to calendar events (releases, vendor dates, audits)?
3. Review every sprint
Before or during Retro, quickly scan the log:
- What changed status?
- What needs escalation?
- What new items do we need to add?
From Theory to Practice: Your Next Step
If you’re a PM or PO, try this: in your next sprint, spend 10 minutes with your team building a living RAID log and commit to reviewing it every Retro for a month. See what changes when risk, assumptions, issues, and dependencies are actually visible.
If you’re a hiring manager or delivery leader who cares about this kind of ruthless honesty in Agile, I’d love to connect. I’m always up for swapping stories about what really works in complex delivery and how we can build healthier, more transparent teams.