Jen's Agile Cliff Notes - ROAM’ing our Risks

In an Agile Release Train (ART), we try to mitigate risks. Some risks can be tackled at a Team level. Some risks are bubbled up to a Program level. Some risks we identify during PI Planning. Other risks are identified during the PI.

In this version of Jen's Agile Cliff Notes, I will explain ROAM’ing in a nutshell. Shall we? (I can’t ROAM a risk without singing the B-52’s song…)

During PI Planning, teams have identified program risks and impediments that could impact their ability to meet their objectives. These are resolved in a broader management context in front of the whole ART. One by one, the risks are discussed and addressed with honesty and transparency, and then categorized into one of the following categories:

● Resolved

● Owned

● Accepted

● Mitigated

Even though the plans are complete, there is still work to do. During the planning, teams have been asked to identify the most critical risks and impediments: those issues they identify that could affect their ability to meet the agreed-upon objectives.

Addressing these is a must for the ART, as they typically represent those things that can—and if not addressed, likely would—interfere with the success of the PI.

By now, the teams should have been coached to address those risks that are under their control; otherwise, they couldn’t be responsible for their own plan. So the risks and impediments that remain in the final review will need to be addressed in a broader management context.

Every program risk that has been identified by the team will be discussed and addressed in front of the full group. Each item is discussed until the group agrees that the item can be categorized in one of the following (ROAM) categories:

● Resolved – The teams agree that the issue is no longer a concern.

● Owned- the item cannot be resolved in the course of the event, but someone (usually a manager or a specific team) takes ownership of the item. Ownership means that the responsible party will take whatever action is necessary to ensure that the issue will not negatively affect the release commitment.

● Accepted – some risks or impediments are simply facts or potential occurrences that must simply be understood and accepted. Nothing further can be done about it at this time. For example, ‘extraordinary support requirements’ for a prior release often appear on the list and can potentially cause a team to miss a future commitment. However, allocating excessive resources just to ensure that these types of risk do not happen will lower value delivery for the release and may not be prudent. Another type of potentially accepted risk might be the ‘late delivery of a component from a supplier.’ Accepted means we’re not taking action. We accept the risk as-is.

● Mitigated – Often, the teams can identify a plan to mitigate the impact of an item. This may be a workaround plan, a minor de-scoping, or any other such actions that the teams can take to lessen the impact of a potential problem. If so, the mitigation plan is identified as notes for the risk.

As always, if you have any questions, you can always reach out to me, and I will be happy to help.