When a team adopts Agile processes, they can sometimes forget to retain the good practices from the “old” processes. One of these forgotten practises is Risk Management. People are going to rightfully argue that Agile will ensure that the constant feedback loops of daily stand-ups, demonstrations and retrospectives make issues more visible and can often raise them earlier than in other processes. However, this discussion is about risks not problems. A risk is a potential issue that has not occurred yet. A problem is an issue that happened and that you need to solve. Agile processes will help you identify problems early, they will not help detect risks. To detect risks and manage them, you need a proper risk management process within your Agile project process.
So, what risk management process can we utilise? Risks, by definition, have to be discovered before they become problems. Therefore, we need proactive actions to find them. When the team is gathered to discuss the product backlog and the iteration backlogs, each member of the team should ask themselves:
• What are the business risks linked to these stories/tasks (e.g. lack of knowledge of the business rules even on user side);
• What are the financial risks (e.g. may require acquisition of an expensive product, or help from consultants);
• What are the technical risks (e.g. performance concerns, unknown technology);
• What are the organisational risks (e.g. dependency on another external team).
The same questions should be asked again during the planning meetings. This is an active process. Everybody should think about these questions and try their best to answer them.
Just answering these questions and identifying risks is not enough. You then need to move to the next step of this process, which is to define a mitigation plan for each risk discovered. The plan does not need to be a full document; a simple sentence can be sufficient, but it must always be completed with a dead line date. The dead line is very important. It defines the time when your risk becomes a real problem. If the risk has not been mitigated by the date specified, then you have a problem that will probably be difficult to solve. You then need to define and apply a resolution plan. In Agile processes, a common way to mitigate technical risks is to define spikes (investigation by prototyping). Once a spike has confirmed a technical solution, this solution can be used in a future sprint/iteration.
For each risk, you can also specify three more very useful piece of information:
• Impact on project if it becomes a problem. It can be a sentence and a grade (e.g. severe, medium, benign);
• Probability of occurrence (e.g. likely, unlikely);
• Cost to mitigate it.
These data will help you assess whether it is worth mitigating the risk. You probably do not want to mitigate a benign risk that is expensive to mitigate and is unlikely to happen.
As for every action and sub-process applied in an Agile project, do not forget to review your risk management process during the retrospectives.