ROAM Risk Management: Suspect the Unexpected

The greatest tragedy that can befall a team is being ambushed by program risks. Although agile development practices can mitigate potential risk, some teams will require a more formal approach to risk management. If you’re looking for a lightweight agile-ish approach, keep reading.

What is ROAM Risk Management?

ROAM is a collaborative, lightweight risk management technique built on a visual, pull-based model.

If risk management and Kanban had a baby, it would be ROAM.

This effective risk management approach uses a board to track risks. Either someone will own the management of new threats, or they’ll be considered complete via one of three categories.

The SAFe (Scaled Agile Framework) framework has popularized ROAM with its usage during PI Planning. Regardless of what opinions you may or may not have regarding SAFe, ROAM is independent and applicable to other agile approaches.

What Does ROAM Stand For?

Roam is an acronym for Resolved, Owned, Accepted, Mitigated.

Each term is a category on the ROAM board that indicates either how we managed the risk or that it is currently still in progress.

Let’s review the nuances of each term.

Resolved

The resolved status indicates that there is no longer a risk.

This state is applicable if the team has taken action to eliminate the risk, or it could be because we’ve verified that the level of risk is non-existent. Either way, resolved indicates that there are no remaining concerns.

Owned

The owned status indicates that someone has accepted responsibility for managing the risk.

Owned is the only status that means the risk still needs to be handled. The other three statuses are all variations of “done.”

Ideally, the team has discussed the mitigation plan. Harry accepts responsibility for executing the plan; therefore, Harry owns the risk.

If there is no defined remediation plan, as the owner, Harry will work collaboratively to develop one.

Accepted

An accepted risk is one that we’ve acknowledged and chose to take no action to resolve.

This decision might be appropriate when the effort to mitigate the risk costs more than allowing the risk to transpire.

Accepting risk is also an appropriate response in situations where we have no options for mitigation or resolution. If there is nothing we can do to prevent the problem, we document that we’re aware of it and move on.

Mitigated

A mitigated risk is reduced but not eliminated.

We’d use the mitigated status when we’ve done all we intend to manage the risk. We won’t be able to resolve all issues entirely. In some cases, the actions required for resolution are cost-prohibitive. We consider a threat mitigated when we’ve reduced the likelihood or impact of the risk, but we intend to take no further steps toward resolution.

I tend to get Resolved and Mitigated conflated. The main difference between these two is that resolved means there is no more risk; it’s essentially been eradicated. Mitigated means we’ve done everything in our power to reduce the risk, but some element of risk remains.

The ROAM board

Above is an example of a ROAM board. Teams commonly use a board similar to a Kanban board to visualize program risks.

This board has a ‘new’ column where we’d place new risks that the team has not yet discussed. After discussion, the card will transfer to the appropriate spot based on the conversation’s outcome.

If the team agrees that no action could or should be taken, the card will transition to the accepted column. If the team could not manage the risk in the immediate discussion, the card would transition to the owned column once an individual had accepted accountability for its management.

The ROAM board includes information about each category and the criteria a card should meet before moving into that status.

Documenting working agreements at the top left helps the team quickly remember any special processing they’ve implemented.

ROAM Risk Example

Those who know me in real life know that I’m irrationally terrified of bugs, and I consider the presence of a bug a risk to my mental health.

When I see a fast-moving bug, I will scream and run for my life. When my husband checks on me out of concern, I inform him of the intruder’s whereabouts. I will send him a picture of the bug’s general location for slower-moving bugs.

In either case, I’ve identified the threat and assigned it to my heartmate, who now owns further management of the situation.

As you can imagine, my husband gets a little exasperated being the sole person responsible for dealing with every single creepy-crawly that finds its way into my space. Thinking that he was enabling me to fend for myself, he purchased what he described as an electric fly swatter. In reality, this turned out to be more like a small tennis racket backed by Thor’s lightning.

Shortly after receiving this, a fat, persistent buzzer fly accosted us. You know, the ones that sound like mini airplanes whizzing past your face. Like any rational person, I took cover under a blanket while my husband swatted at the fly with this racket. There was a loud pop upon contact, and the buzzing instantly stopped.

There is a non-zero chance that the racket vaporized the fly, but my hero was relatively sure he saw its body land in the corner of the bedroom. Upon further investigation, we could not spot the corpse, but neither did we hear or see the fly.

This is an example of a mitigated risk. If we’d been able to confirm the death of said fly, the risk would be resolved, but since there is still some chance that it lies in wait for the perfect opportunity to get its revenge, we can only say that it’s mitigated.

In cases where my husband successfully kills the offender and there is a carcass for proof, we can say those risks are resolved as the invader poses no further threat.

I’ve learned to pick my battles over the years and save my requests for rescue for the more horrifying bugs. For instance, I can deal with the common housefly as long as they just get stuck in a window behind blinds, quietly struggle, and die peacefully.

The effort of resolving the risk outweighs the reward. Since I cannot bring myself to squash the pest, I just accept this risk and move on.

Benefits of ROAM Risk Management

“If you don’t invest in risk management, it doesn’t matter what business you’re in, it’s a risky business.”

-Gary Cohn

Proactive

Once we start using the ROAM technique at a team level, it helps us to remember that risk management is something that we should consider regularly. In doing so, we become more proactive in our risk management efforts instead of reacting to each fire as it starts.

Actionable

The three done states of ROAM, resolved, accepted, and mitigated, really help frame what our next actions should be. Is there a way to resolve this risk? If not, then can we at least mitigate it in some way? Do our potential actions cost more than just allowing the problem to occur? If we can’t resolve or mitigate it, we need to accept it and move on.

Scalable

The approach is an effective risk management strategy for individual teams or the entire organization. The simplicity of the technique makes it more likely to be adopted throughout the whole organization.

Simple

Although this approach lacks formality, ROAM will likely suffice as adequate risk management when coupled with an agile project management approach. The easy-to-remember statuses contribute to the simplicity of ROAM, and simple techniques tend to be less brittle, require less training, and have a higher adoption rate.

ROAM Best Practices

Phil Gardiner’s presentation on The Fall and Rise of ROAM does a great job covering pitfalls and best practices. Below are some recommendations to ensure success.

Review Cadence

Proper risk management should be a continuous practice. Successful teams will either review the ROAM board in an existing recurring meeting or establish a specific session for reviewing the risk board.

The Daily Scrum or the Sprint Review events are good contenders for incorporating risk review for teams following Scrum.

The important thing is that we revisit the items regularly to ensure we’re making progress and capturing any new threats.

Shared Ownership

Accountability for risk management falls to the whole team. An anti-pattern is to always assign ownership to the Scrum Master or a similar role. If this individual gets overloaded, it could delay the resolution of an issue.

Like any other agile work item, anyone with the necessary skill should be able to resolve a risk. The team will be better off the more people they have resolving threats. We want to avoid making one person responsible for all issues, effectively introducing a single point of failure.

Working Agreements

Over time, the team might agree to specific guidelines around managing risks. These guidelines may have evolved from a retrospective or other lessons learned from past experiences.

It can be helpful to document these working agreements on or near the ROAM board. Otherwise, even the best of ideas can be easily forgotten.

Some examples of working agreements you might see on a ROAM board are:

• Accept any risk with an impact below a certain threshold
• Mitigated risks must include documentation of the mitigation plan

Works Consulted

• PI Planning
• ROAM Board Pitfalls and Best Practices
• ROAM(ING) DAILY SCRUM MEETING
• ROAM & Risk Management Under SAFe®

TLDR

If your team struggles to proactively manage risk, introducing the ROAM risk management technique can be an easy and painless way to avoid the surprises that are likely to cause your team to slip.