Navigating Software Risks: A Deep Dive into Risk Storming

The world of software development is rife with risks and uncertainties, from unexpected technical glitches to sudden changes in the team dynamic. To deliver and maintain a successful product, one needs to be aware of these potential pitfalls and have strategies in place to mitigate them. This is where Risk Storming comes into play.

Risk Storming is a visual, engaging, and highly effective risk management approach involving the entire software team. Its primary goal is identifying, evaluating, and developing contingency plans for both existing and potential risks. This ensures a smoother development journey and higher success rates.

In this blog post, we will delve into the concept of Risk Storming, exploring its integral aspects and demonstrating how to implement it effectively in your software development process. Whether starting a new project or managing an ongoing one, Risk Storming can offer invaluable guidance to help navigate challenges.

What Is Risk Storming?

In simple terms, Risk Storming is a team-based exercise designed to identify, prioritise, and strategise around the various architectural, delivery and maintenance risks of software products. It enables teams to visually map out potential challenges, assess their impact, and devise strategies to mitigate or eliminate them.

At its core, Risk Storming involves three fundamental steps:

1. Risk Identification

The first stage of Risk Storming invites the entire team to recognise potential risks that might plague the project. This phase is about fostering open communication and encouraging team members to bring forward their experiences, perspectives, and insights. Everyone’s input is essential — from the developers who understand the technical intricacies to project managers who oversee the bigger picture.

2. Risk Assessment

Once risks have been identified, the team then evaluates their impact. Some risks might bring minor disruptions, whilst others could jeopardise an entire product. By understanding the magnitude and probability of each risk, the team can prioritise which risks require immediate attention and which can be monitored over time.

3. Risk Mitigation

The final stage of Risk Storming is all about problem-solving. The team collaborates to devise strategies that can reduce the impact of specific risks or the likelihood of a risk event occurring. This phase involves designing contingency plans, making architectural changes, or, if necessary, adjusting the project’s scope.

With these steps, Risk Storming provides a structured yet flexible approach to managing risks in software products. It creates an environment of shared understanding and collective responsibility, empowering teams to navigate through uncertainties with confidence and control.

When to Use Risk Storming?

Risk Storming is a versatile technique that can offer value in various situations within the software development lifecycle. Whilst it’s hard to find a situation where Risk Storming would not bring benefit, certain scenarios particularly call for its proactive risk management approach.

1. New Projects

Risk Storming is invaluable if you’re about to kick-start a new project. It allows your team to anticipate the myriad of challenges and uncertainties associated with building software from scratch. By conducting a Risk Storming session before the project begins, you ensure risks are identified, prioritised, and strategised for right from the get-go.

2. Large Scale Refactorings

Planning to refactor a substantial part of your codebase? Refactoring is notorious for its propensity to introduce bugs or unforeseen complications. Risk Storming can help the team identify potential risks associated with the intended changes and devise a mitigation plan, ensuring the refactor proceeds smoothly and with fewer hiccups.

3. System Migrations

Whether it’s a database migration or moving an entire infrastructure to the cloud, such significant changes are fraught with risk. Using Risk Storming in these situations helps identify possible challenges and bottlenecks, assess their impact, and strategise mitigation plans well ahead of time.

4. Feature Additions

Introducing new features can pose its own set of risks, from technical challenges to impacts on existing functionality. A focused Risk Storming session on the proposed features can shed light on potential problems and aid in devising strategies to tackle them effectively.

5. Post-Incident Reviews

Finally, after a significant incident, conducting a Risk Storming session can be a powerful exercise. The team can identify what risks were realised, evaluate the effectiveness of their previous strategies, and update their risk profiles and mitigation strategies accordingly.

6. How to Perform a Risk Storming Session

Risk Storming is as much about the process as it is about the outcomes. Conducting an effective Risk Storming session can be broken down into a series of structured steps, ensuring a comprehensive review and strategy formation. Here’s a step-by-step guide on how to run a Risk Storming session:

Preparation

1. Define the Scope

Before anything else, it’s crucial to define the scope of the session clearly. Are you focusing on the entire project, a specific feature, or perhaps a component of the architecture? The scope will guide the risks you’ll identify and strategise around. Once you know the scope, you need to provide a diagram that covers this scope. For example, if your scope is for the backend APIs of a system, then you will need the architectural diagrams that cover the elements that make up these APIs. You should use diagrams with the level of detail of the risks you want to identify. If you want to find high-level risks, use high-level diagrams. If you want to find the risks around the nitty-gritty detail of specific functions and classes, use detailed code-level diagrams. Documenting your architecture, preferably using a framework such as the C4 model, can be highly beneficial.

2. Identify Architectural Characteristics

An architectural characteristic, also known as a “quality attribute”, is an attribute or property that can be used to evaluate the performance or behaviour of a system. Architectural characteristics might include:

1. Security: How well the system can protect data and resist attacks.
2. Performance: How quickly the system responds to user actions or system events.
3. Scalability: The system’s ability to handle increased loads, such as more users or operations.
4. Reliability: How well the system prevents or recovers from failures.
5. Maintainability: How easily developers can understand, correct, and modify the system.
6. Usability: How easy it is for users to understand and use the system.
7. Portability: The ease with which the system can be transferred from one environment to another.

In the context of Risk Storming, you should decide on the architectural characteristics of the system or component under consideration that you want to assess the risk of. For example, you might want to review the security risk imposed by adding a new feature to an application. Or the current risks limiting the scalability of your frontend application. Each characteristic requires its own storming, and although you can tackle a couple of characteristics in a single session while you have everyone’s attention, taking on too many can easily result in tired and confused participants.

3. Decide Who Should Be Involved

The value of the Risk Storming exercise is gained from gathering opinions from a diverse range of team members. These should include developers, testers, project managers and architects. Each person will come with their own experience and relationship with the software. The diverse perspectives enrich the identification and evaluation of risks.

4. How to Measure Risks

To prioritise which risks should be addressed first, each risk needs to be measured. This is done by considering the impact and likelihood of each risk occurring. The bigger the impact and the more likely it is to happen, the higher the priority to mitigate the risk.

When measuring risk, the team should use the following matrix to give each risk a score:

So, if a risk has a low likelihood of occurring and a low impact, it would score “1”. However, if there’s a high likelihood of it occurring and a high impact, then the score would be “9”.

This method results in each risk having a score and also fitting into one of three groupings, Low (green), Medium (amber) and High (red), making it easy to prioritise.

The Risk Storming Session

1. Set The Context

Send out the details of what’s being assessed to everyone involved. Each person needs to know the scope being considered, given the relevant architectural diagrams that represent that scope at the appropriate level of detail and told what architectural characteristic(s) are being assessed.

2. Identify Risks Individually

Each person is asked to initially brainstorm potential risks associated with each architectural characteristic by themselves. The individuality of this step helps ensure everyone’s opinion is captured and each person is not distracted by others’ thoughts. They should place a post-it note (or online equivalent) on the diagrams over the area where the risk exists and write down the score they would give that risk using the matrix discussed above. This step is about quantity over quality, and all risks, no matter how big or small, should be noted. This process needs to be done separately for each architectural characteristic being assessed.

3. Evaluate and Prioritise Risks Together

The team must now come together to review all the identified risks. Once each individual’s risks are shared, the team collaboratively assesses each risk’s probability and potential impact. It is often the case that the same risk is identified multiple times but with different scores. This is the perfect time for the team to share their understanding of these risks and discuss why they have chosen the scores they have. This dialogue allows the team to understand each other’s perspectives and reach a consensus to agree on a final score for each risk. At the end of this step, the team will have a list of all the understood risks and their relative priority.

4. Develop Mitigation Strategies

For each prioritised risk, the team then devises strategies to either mitigate its impact or decrease its likelihood. The strategies should be specific, actionable, and assigned to a responsible person or team.

5. Review and Document

Finally, review the entire Risk Storming session and document the risks identified, their prioritisation, and the corresponding mitigation strategies. A great item to include in this report is a risk assessment matrix. This presents a great visual summary of the risks identified and helps highlight both the individual areas of the system and the architectural characteristics which have the highest risk.

This document will serve as a vital reference, informing decisions and providing guidance for future work on the system.

Conclusion

By following these steps, your team can conduct an effective Risk Storming session, enhancing your ability to navigate the uncertainties and risks inherent in software development with greater foresight and preparedness.

The key is to promote open and honest communication, foster collaborative decision-making, and encourage collective ownership of risk management.