In this article we outline a few simple techniques that can be applied in your daily agile risk management work. For more details please refer to any of our publications relating to risk management in agile projects and wider agile management or get in touch with us. Throughout we will be using the following model as described in Managing Risk in Agile Projects
First off, let’s be clear that we are referring to project risk management i.e., operational rather than strategic risks. Moreover by risk itself we mean any uncertainty that has either a positive or negative impact on one or more project objectives. This means that a risk must have elements of both uncertainty and impact and that the realisation of a risk can have upside as well as downside implications. To quote a metaphor from “Agile Risk Management” the outcome of a horse race may well be uncertain but only becomes a risk once a bet has been placed (at which point the uncertainty translates into an impact on the goal of making money!)
1. What/Why Technique
The first stage in agile risk management concerns the identification of risks. This is harder than one might imagine owing to our propensity to conflate effect and uncertainty. The key to differentiating between effects and uncertainties lies in the what/why technique as described in Managing Risk in Agile Projects which can easily be applied to just about any agile undertaking (e.g., Sprint planning of Scrum projects).
2. Risk Log
The risks identified using the what/why technique (i.e., the “why” statements) may be recorded in a register but only in so far as this facilitates analysis and scoring (i.e., the practice of categorising likelihood and impact). The important point here is not to assign ownership since it must be down to the team to assume responsibility for the associated risk activities using an appropriate pull-based approach (e.g., Kanban). A risk log is therefore merely a transitory artifact used to capture and record details that can be acted upon later. It is managed and owned by the entire team.
3. Risk Rainbow
The analysis of risks endeavours to attribute scores to the two distinct risk components (i.e., likelihood and impact) with the purpose of suggesting courses of action and assigning priority. It is as important here not to lose oneself in analytical details as it is to recognise uncertainty in the analysis itself (e.g., when unsure about the impact then perhaps use a range rather than a point estimate). The following diagram, referred to as a risk rainbow in “Managing Agile“, maps risk score co-ordinates to likely risk response strategies and can be used to stimulate discussion. Note that we consider both the mitigation of threats (i.e., negative risk) as well as the exploitation of opportunity (i.e., positive risk).
For example, suppose that a (negative) risk is analysed to have medium impact and medium likelihood. Then according to the risk rainbow it might be appropriate to engage in a risk reduction activity (i.e., “Reduce”). Of course this does not have to be that way, but it is generally a good starting point. Discussions within the team should clarify further if this is the correct approach to adopt. The most common strategies are reduction (of negative risk) or exploitation (of positive risk) together with avoidance (i.e., not performing the underlying activity that gave rise to the risk in the first place), transfering (i.e., getting a third party to bear the risk e.g., insurance), sharing (i.e., splitting risk and reward with others) or accepting (i.e., admitting that the risk might occur since to act now might not be effective in terms of cost-benefit; usually though a contingency plan is put into place).
Now suppose there was disagreement in the team about whether or not the impact was really medium (e.g., some team members think that the impact could be high). Then discussion should focus on whether to avoid the underlying task that gave rise to the risk in the first place or whether to continue to try to reduce the risk (as marked by the oval above). This is an action oriented discussion that does not consider further the technical details of impact analysis as these quickly become irrelevant.
Suppose, on the other hand, that the team was in agreement about medium impact but thought the likelihood could range from medium to high. This time the rainbow suggests that irrespective of the outcome a “reduce” strategy will be pursued and that the only question which remains is how much priority to give that risk mitigation activity. Once again this is an action oriented discussion this time focusing on prioritisation.
4. Risk Tasking and Risk Tagging
Once a course of action has been decided this needs to be planned for and enacted: generally speaking this boils down to either what needs to be done or how something needs to be done.. Risk Tasking (“what”) refers to the practice of creating a task that describes what needs to be done which should appear on the backlog or Kanban alongside all the other stories and tasks that the team need to attend to. Risk Tagging (“how”), on the other hand, means annotating existing tasks to indicate how they are to be performed in such a manner as to better treat the associated risk (e.g., perhaps all GUI tasks must be done using pair programming together with the customer). In practice most risks can be treated with some combination of tasking and tagging.
5. Risk Modified Story Map (or Kanban Board)
Risk Tasking and Risk Tagging can be easily visualised on an existing user story map if the risk tasks are coloured appropriately (e.g., red for threat reduction and green for opportunity exploitation) alongside the tagging of existing stories to indicate the application of agile practices for the purposes of risk treatement. Together these create a convincing visual representation of risks are being treated.
This very same technique can equally be applied to Kanban boards (or other existing agile artifacts) to communicate how risk treatment is progressing.
6. Risk Burndown
The tracking of risk treatment activities requires that the initial assessments made during analysis be reviewed once a course of action has been determined and enacted. This is where the Risk Burndown comes into play as it indicates not only how differences between inherent (i.e., untreated) and residual (i.e., risk that remains after a treatment has been applied) act to reduce overall risk but also how there always remain some systemic risk affecting the project. Calculating risk burndown is, however, not as straightforward as might appear at first sight. For example, some risk treatments themselves introduce new risks (sometimes known as secondary risks) and the impact of risk tagging also needs to be taken into account as described in “Agile Risk Management” or “Managing Agile“.
Risk Burndowns enable the computation of risk metrics such as the iteration managed risk ratio that describes progress towards tackling treatable risk. Generally speaking the application of a Risk Burndown at the appropriate level (e.g., project, increment or iteration) also needs careful consideration by the team.
…and then some!
Often the value of these techniques becomes apparent in their interaction with each other or the application of other agile risk management techniques not listed above. Indeed agile risk management as envisaged by the IARM endeavours to go significantly beyond the mere grafting of traditional project risk management practices into the agile arena by providing real measures that blend into the agile way of thinking.