Do Agile and Hybrid Projects Still Use Risk Registers?

A team moves to two-week iterations, and within about a month the risk register has quietly stopped being updated. Nobody decided to abandon it. It simply stopped earning its place in how the team worked, while the assurance calendar carried on expecting a monthly submission. Someone then rebuilds it from memory the night before the board meeting, which produces a document that is technically present and practically useless.

The short answer to the search question is yes. Adaptive and hybrid projects still record risk, and most still keep something recognisable as a register. What changes is the form, the cadence, the level of detail and who is expected to act. The register that fails on an Agile team is usually not failing because the team is Agile. It is failing because it was built to be reported rather than used.

The register is a decision aid, not a delivery style

Strip a risk register back to its function and it is a short list of uncertain events that could affect the project, each with an assessment, an intended response, a named owner and a current status. Nothing in that description belongs to predictive delivery. What tends to belong to a particular era of practice is the way organisations surround it: an annual identification workshop, ninety entries of varying quality, a heat map produced for a steering group, and a review cycle slow enough that the register describes the project as it was rather than as it is.

The Risk Performance Domain in Section 2.7 of the PMBOK® Guide treats risk as uncertainty that may affect objectives, covering both threats and opportunities, and it does not attach that thinking to one development approach. That framing is useful here because it separates two questions that often get merged. Managing risk deliberately is not optional in any approach. Maintaining a particular document, at a particular size, on a particular monthly rhythm, is a tailoring decision.

The vocabulary needs to stay straight as well, because mixed teams often blur it. A risk has not happened yet. An issue is already occurring and needs managing now. Uncertainty is the wider condition, including ambiguity and variability, that surrounds both. Teams that stop distinguishing these tend to end up with a register full of current problems and no forward view at all.

Where risk actually lives on an adaptive team

Adaptive teams do a great deal of risk work without ever calling it that. Ordering the backlog so that the least understood component is built first is a risk response expressed as a decision about sequence. A spike to prove an integration, a thin end-to-end slice through an unfamiliar architecture, an early performance test, a definition of done that forces security review before an item is accepted: each of these reduces exposure earlier than a written mitigation ever would. Iteration reviews and retrospectives also work as detection points, because they bring the same people back to the same questions every fortnight.

That is genuine risk management, and it handles a particular class of risk very well: uncertainty the team can act on inside its own delivery cycle. What it handles poorly is everything else. A supplier whose contract renewal sits with procurement, a regulatory submission date that will not move, a dependency on a system owned by another part of the organisation, a funding decision expected in three months: none of these can be resolved by a card on a board, and none of them will be visible to anyone outside the team if that is the only place they exist.

This is the practical reason the register survives. It carries risk memory across iterations, holds items with lead times longer than the team's planning horizon, and makes visible the risks that require someone with more authority than the team has. Remove it entirely and the team is not managing risk with less bureaucracy. It is managing a narrower set of risks and hoping nobody else's risk arrives uninvited.

Hybrid delivery: one risk picture, two rhythms

Hybrid projects fail on this in two opposite directions. The first is separation, where the adaptive stream keeps risks on the board, the predictive stream keeps them in the register, and nobody reconciles the two, so the project has two partial pictures and no complete one. The second is duplication, where every card is copied into the register in the name of consistency, doubling the administrative load and halving the accuracy, because nobody can keep two versions of the same thought current.

The workable middle ground is an agreed rule about what gets promoted. Team-level risk stays with the team when the team can assess it, act on it and absorb the consequence within its own cycle. It moves into the project register when at least one of a small number of conditions applies: it crosses a stream boundary, it exceeds the team's authority, it threatens a committed date or an external obligation, it needs money the team does not control, or it will still be live beyond the current planning horizon. Agree that rule once, with the delivery leads present, and most of the argument about documentation disappears.

Consider a regional utility replacing its customer billing platform. The software build runs in two-week iterations. The data migration and the field-device replacement run to a fixed sequence with a regulatory reporting date attached to it. For several iterations, the team's retrospective notes that extracts from the legacy system keep arriving incomplete, and the team works around it each time. On the board it reads as a delivery irritation rather than a risk, so it never reaches the project register. Three months later the migration rehearsal cannot be scheduled with confidence, and the reporting date is suddenly in question.

The judgement worth extracting from that is not that everything should have gone into the register. It is that a recurring impediment which touches another stream deserves one deliberate test against the promotion rule. Applied at the time, the outcome is modest: a single register entry, an owner in the data team rather than in the delivery team, a response with a date, and a threshold that says what happens if two more extracts arrive incomplete. That is a few minutes of work that changes who is watching and when they act.

Before you remove the register, ask what it is doing

When a team wants to drop the register, the useful questions are practical rather than doctrinal. Who reads this, and what decision have they made differently because of it? Which entries are outside the team's authority to resolve? Which are really issues that should be managed now rather than tracked? How long does it currently take between a risk becoming visible to someone and reaching someone who can act? If the honest answer is that nothing changes because of the document, the fault is normally in the cadence, the ownership and the level of detail, not in the existence of a register.

For a PMP candidate, the important distinction is between the practice and the artefact. Preparation material sometimes leaves the impression that registers, baselines and formal documentation belong exclusively to predictive delivery, which makes "the approach is Agile, so the register does not apply" feel like sound reasoning in a situational question. It is not. The stronger habit is to read what the situation actually requires: whether the uncertainty can be acted on by the people in front of you, who needs to know, and what form of record supports the decision that has to be made. If you want to work through that kind of tailoring judgement in a structured instructor-led setting, the PMP® Exam Preparation course applies the same reasoning across the wider syllabus.

On a live project, the test is simpler still. A risk record is doing its job when someone with the authority to act sees the right item early enough to make a different decision. If your register does that in three pages reviewed fortnightly, keep it. If it does that as a short list on a wall alongside a project-level view for the risks the team cannot own, keep that instead. The delivery approach tells you how to shape the record. It does not tell you that you no longer need one.

Andre Malowney

Interested in going further?

Deciding which risks belong to the team, which belong to the project and which need a sponsor is one of the judgement calls that shows up repeatedly in mixed delivery environments and in situational exam questions alike. Structured preparation gives you a consistent way to reason about it rather than relying on whichever documentation habit your last organisation happened to use.

If you want to read the underlying treatment of risk, threats and opportunities in full, the Risk Performance Domain in the PMBOK® Guide Eighth Edition is the relevant source.

Ad · Amazon affiliate link.

References

A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
A060: Why Hybrid Projects Use Agile and Traditional Artefacts Together
A154: When Does a Risk Become an Issue?
A164: Risk Owners vs Action Owners
A165: Tailoring Risk Management to the Project

PMP and PMBOK are registered marks of the Project Management Institute, Inc.