Agile Risk Management
Risk management happens every time we evaluate the outcomes of different solutions in our heads. Sometimes, because of communication necessities or legal requirements, risk management has to be made visible. It is usually at that point when a consultant is hired and a ridiculously expensive software system bought. Really, don’t do that. In the following few paragraphs I will describe an approach that fits to your existing agile development model and fulfills the requirements of most risk management standards. I have experience from ISO 14971.
Let’s first revisit the basic concepts of risk management. A risk is a threat, which could lead to a harmful situation, which could cause harm. Risk is typically measured by the probability of the harmful situation occurring and the effect of the harm. A common approach is to measure probability and effect on a scale from one to three, which when multiplied represent the risk. Risk management is a continuous process. It starts with the identification of threats. Scenarios of harmful situations and harm are produced together with an assessment of their probability and effect. If the resulting risk is unacceptable, control measures are implemented and followed by a reassessment of the threats for possible residual risk.
Now that doesn’t sound so bad, does it? And the fact is that it isn’t. When we manage risk the agile way, each threat is actually an epic. During planning sessions risk epics are split into user stories just like all other epics. A typical user story is formatted like this: “As an <user>, I would like to <do something> because <reason>.” When talking about risks, we slightly revise it to something like this: “Because of <a threat> it is possible that <a harmful situation>, which could lead to <a harm>.” Here’s an example: “Because results can be accepted without confirmation, wrong blood test results could be accepted by accident, which could lead to severe complications for the patient from wrong treatment”. My motivation is that when risks are expressed in a concise way like this, they can be understood by business and technical people alike. And honestly, who wants to read those lengthy yammerings anyway?
During planning each risk story is given probability and effect figures, from which the priority of the story (= the risk) is derived. If a risk story prioritizes high enough, it is moved into implementation like any other story. When the story is implemented, it actually counts as risk control measures. Evaluating the residual risk — or effectiveness of risk control measures — is part of definition of done for risk stories. No risk story is done until the risk is acceptable. Additionally no release can be made, if there are high prioritized risk stories open. A detail is, how to relate numerical risk figures to story priorities and risk acceptability. I’ve used an approach where risk from 1 to 3 was low, 4 to 6 normal and 7 to 9 high, which was unacceptable.
In addition to managing individual risks, any good risk management practice takes into consideration the total risk. The concept of total risk states that while all individual risks are acceptable, their sum might not be. For example there might be so many risks affecting some functionality, that the overall probability of something bad happening becomes too high. The result is that individual risks have to be controlled more. Calculating total risk from individual risks is something that can be done automatically by the system holding the risk stories. In agile risk management, total risk is also part of definition of done. It should never rise above a predefined threshold. I’ve used an approach, where the total risk was not allowed to rise over 5n, where n is the amount of risk stories. In other words the total risk had to stay on the lower half of the risk scale.
An additional aspect of risk management is that previously identified risks are revisited on a regular basis to make sure that they are still acceptable. This is a practice that could be undertaken during sprint planning sessions or at release demos. Risks that were never controlled — those that never prioritized high enough — can be left open so that they get automatically re-evaluated. Both issues are matters of opinion.
Why is agile risk management better than then traditional way? Because the agile way involves everyone. Collaboration and commitment are in the core of agile. It is the whole team, who participates with their views in evaluating the risks and commits to controlling them. Risk management is not anymore something that is a process — a separate activity. It is in the process — a continuous activity. Since risk management is typically involved when severe harm — as severe as loss of life — could result, making it everyone’s daily responsibility is the only approach.