The importance of managing risks in your software projects need not be further emphasized. Even if you're not working on safety-critical products, risks have the potential to fundamentally derail your projects. With safety- or mission-critical projects however, it is even more obvious that risks mean a serious threat not only to your project's success, but also to your company's reputation. At the very least, implementing adequate risk management could help cut your overhead costs.
So one thing is clear: managing risks is imperative in most product development projects. That is why several times over the past few years, we have covered topics such as the Benefits of Applying an Appropriate Risk Management Lifecycle or Agile Risk Management in Digital Safety-critical Product Development on our blog, and we've also organized webinars around related topics.
Considering that more and more companies are transitioning to an Agile methodology to deliver complex products, however, risk management is becoming more of an issue. While a single Agile team may successfully cover and mitigate its risks using simple methods, large enterprises that scale Agile using SAFe® face the challenge of also scaling their risk management activities.
There is no silver bullet solution to scaling your risk management across the various levels introduced by the Scaled Agile Framework (SAFe®). Previously (before SAFe 5.0), this meant the Team, Program, Large Solution, and Portfolio levels. With the latest version of the Scaled Agile Framework, you're looking at the Essential, Large Solution, and Portfolio levels. While there's no one-size-fits-all solution, a general best practice is that categorizing your risks helps treat them adequately.
Quite naturally, most practitioners agree that code-level risks are managed at the lowest level, during Program Increment planning. Higher-level (project or program) risks that could affect the whole Agile Release Train (ART) should be escalated to the Program level. Thus, your teams won't have to worry about the same risk twice – all risks will be identified, documented, and their mitigation planned at the appropriate level. (While there may be certain Portfolio-level risks, managing these should be covered by the organization's Project Portfolio Management or PPM efforts, the details of which is outside the scope of this article.)
Whichever level you're looking at, one widely used tool in scaling risk management under SAFe® is the ROAM board. It is used during PI planning to identify and analyze risks and issues that could prevent the team in successfully achieving its goals. To make sure all the risks are covered, the goal of this technique is to Resolve, Own, Accept (by the product management team), or Mitigate all risks.
Resolved: Participants can agree that the risk is no longer a concern and can therefore be disregarded.
Owned: Each and every risk that is not solved right away during PI planning must be taken on by a team member who will be responsible for making sure the risk is managed.
Accepted: Certain risks pose a potential problem or cannot be reasonably mitigated. Teams on the Train have to fully understand the details of these risks before accepting them.
Mitigated: A plan is devised to reduce either the probability, or the impact of all identified risks.
Among these groups, Owned stands alone as the only category that is not an end point in itself: the fact that a risk is owned doesn't mean any actual mitigation plan or work has been done. Because of that, it's important have procedures in place to follow up on these risks, making sure their mitigation is actually planned and executed.
Once work has started, there's a good chance more risks will surface. Therefore, executing the ROAM process should become a continuous practice to make sure new and changing risks are taken into account and adequately managed.
Potential issues that are solved on the Team-level ROAM board don't get transferred onto the Program-level ROAM board. The mitigation of the identified risks can follow a course similar to that of any task in an Agile project, but will have to be monitored to make sure ROAM goals are reached.
The main benefit of using a ROAM board is that it helps ensure that all the risks are covered: after a ROAM session, you should have gotten commitment from team members to resolve all the identified risks, and a plan in place for mitigating each of them. Another benefit is that ROAMing can be simply moved to a collaborative risk management tool, facilitating cooperation between geographically distributed teams and ensuring adequate documentation.
Collaboration is key in risk management: identifying potential risks is supported by the cumulative experience of your team members, and having your risks in a single tool helps ensure total risk coverage. Using a tool that simultaneously supports the implementation of SAFe® across your organization while scaling your risk management efforts provides a huge advantage. What's more, such a tool will help ensure the complete traceability of risks and their coverage with mitigation actions.
Codebeamer is not only the first proven implementation of SAFe®, it also comes with advanced risk management functionality. The Kanban board in Codebeamer is a flexibly customizable tool that you can easily use to conduct ROAM sessions. Predefined, but fully customizable risk trackers help you ensure adequate risk documentation, complete traceability, and risk coverage. After ROAMing your risks, you can simply assign mitigation tasks, monitor their delivery, and trace these assets through to testing & release.
Risk Matrix Diagrams support your risk mitigation efforts and ROAM, facilitating the acceptance of risks below a certain tolerable level by visualizing your risks. Thus, using a SAFe®-ready ALM to manage all your development processes helps you scale risk management, while offering all the benefits associated with using a single-repository, end-to-end Application Lifecycle Management solution.
SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile Inc.