Scaling Agile and Risk Management: An Overview

Risk management in agile software development is a complex topic for most organizations, but especially for larger ones at enterprise level. Read on to learn more about the basic principles of incorporating risk management in Agile and how to best tackle the challenge when it comes to scaled Agile methodology in large enterprises!

The various frameworks for scaled Agile (including Disciplined Agile Delivery, Large-scale Scrum, or the Scaled Agile Framework®) enable large organizations to increase their development speed and productivity, manage uncertainty more adeptly, and reduce risks throughout the process. And it’s true that many teams using Agile naturally incorporate risk management practices across the various phases of product development by nature of the mindset. 

However, this has also led to a common myth: namely that Agile organizations don’t need a formal Agile risk management framework, since the mindset appears to be built into the methodology itself. The reality is that in order to effectively scale Agile and risk management alongside each other, organizations need to employ a scaled agile framework for risk management at every stage of the product development cycle.

So although Agile practices in and of themselves do naturally promote iterative risk management, software development teams shouldn’t make the assumption that they’ve covered all the bases without taking structured steps to manage risks throughout the process. This is especially true for larger teams or organizations which have several Agile teams working on the same product. At a high level, the key to effectively incorporating risk management processes in Agile is pretty simple. Start by making sure to identify, evaluate, and monitor risks at both the project and iteration level.

Agile and Risk Management on a Project Level

In order to understand how to scale Agile and risk management, it’s important to understand where to include it on a foundational level first. Risk management needs to be incorporated at the beginning of the project, throughout the development process, and at the end of each project. Let’s explore the individual stages where Agile risk management is vital:

• Risk Identification

After the stakeholders have come together to determine an exhaustive list of requirements for the project, it is time to come up with the risks associated with the project.

• Risk Planning

Following the identification of known risks during the initial planning session, stakeholders create an action plan (or a contingency plan) to mitigate the risks that have been highlighted. Then they create a Project Risk Register, which is updated throughout the project as new risks emerge.

• Risk Monitoring

Risk monitoring occurs throughout the project. This refers to keeping an eye on the risks which were identified earlier, as well as updating the Project Risk Register with how they are handled (and ideally closed) as well as any new risks which pop up along the way.

• Risk Reviewing

This takes place at the end of the project when the Project Risk Register has been updated with how risks were handled throughout the project. This can be reviewed and evaluated to come up with lessons learned and best practices for the future.

Zooming In: Agile and Risk Management on an Iterative Level

Once risk management practices are in place at a project level, it’s important to find ways to incorporate the same behaviors and mindset on an iterative or Scrum level (depending on which Agile framework you use in your organization). Here are some examples of stages when risks should be taken into account which mirror what happens at the project level but on an incremental level:

• Sprint planning: at the start of an iteration in the planning meeting (by creating a forecast, sprint backlog, sprint goal)
• Daily scrum: i.e. during iteration execution, while checking the progress and discussing project blockers
• Sprint review: the perfect time to check up on risks while discussing the current iteration, which might affect the backlog
• Spring retrospectives: what risks came up during the last iteration, how did you deal with them, and what could be handled better in the future.

Now all of this sounds pretty straightforward so far, but what if your organization uses an approach like the LeSS Agile framework, the DAD Agile framework, or SAFe for example? In larger organizations, there are usually a variety of teams working on a product, which is why approaches like the SAFe scaled agile framework emerged to support the increasing popularity of agile process models in larger companies. 

While Scrum and Kanban in their simplest forms work wonders for single teams or smaller companies, it can be hard to continue at that level when there are a number of agile teams collaborating on the same project. These limits also apply to the application of risk management in Scaled Agile frameworks: typical Agile practices which lend themselves well to transparent risk management (daily scrums, reviews, retros, etc) are not as easy to manage when you’re talking about a group of teams collaborating in a huge company on multiple levels.

With more and more organizations implementing Agile at scale, it became apparent that they needed a scalable way to incorporate risk management in agile projects — which is where ROAM risk management comes in.

What is ROAM Risk Management in Agile Projects?

The ROAM risk management model is a collaborative and proactive way to scale Agile and risk management in large organizations. ROAM stands for Resolve, Own, Accept, and Mitigate — four options for how to face potential risks and handle them properly throughout SAFe agile software development, or with whichever scaled Agile model you may be using. First, a risk is identified, then assigned to one of the following categories:

1) Resolved:

The risk is no longer considered to be a threat and doesn’t require any further action (other than, of course, documenting any actions taken to resolve it).

2) Owned:

If the risk cannot be resolved at the meeting, a team member is assigned to ‘own’ or handle the risk and has to make sure that it is properly managed.

3) Accepted:

If the risk cannot be handled or neutralized, the team must accept it and deal with it as it arises.

4) Mitigated:

Then a plan is formed to mitigate the threat of the risk.

Once the risks have been sorted into the above categories, the team votes on which risks are the most important to work on. Those falling into the first three categories (Resolved, Accepted, or Mitigated) are dealt with during the PI planning session, while those which fall into the ‘Owned’ category take a little bit longer to resolve. 

Then of course, new risks are discovered once the work starts, and the ROAM risk management model is used to manage them as they appear. Many organizations that use enterprise Kanban tools leverage the same method to organize their risk management efforts, by creating a ROAM board during the PI planning stage. This is where the right tooling for visualization, transparency, and collaboration becomes essential.

Collaborative and smooth Agile and Risk Management is possible

Integrated Application Lifecycle Management tool support risk management by establishing a central, shared development platform for all contributing stakeholders. By managing and providing insights into all phases of product delivery, ALM tools like Codebeamer help incorporate mature risk management processes into scaled Agile processes.

Codebeamer comes with advanced risk management functionality built-in, a flexible Kanban board that makes ROAM sessions easy to manage, and customizable risk trackers that you can adapt to your own needs. All of these elements ensure proper risk documentation with high levels of traceability and risk coverage. 

By identifying risks early on in the process, organizations can prepare and reduce their impact or mitigate them entirely, as well as easily comply with regulations like ISO 14971 and IEC 60812, not to mention the risk-related requirements of ISO 26262, IEC 61508, IEC 62304, IEC 60601, DO-178C, and other safety-critical regulations.