Agile Risk Management

Well, we all know that Risk is an adverse impact to a Project or Program execution which may end up in a jeopardy.

Irrespective of the methodology that you use to manage the Project either traditional Plan Driven Project Management (PMBOK) or Agile Project Management, you must manage your risk timely.

This Article is about Agile Risk visualization and management.

This is how PMI compares the Traditional vs. Agile Risk Management.



We need to follow simple 4 sequential steps when dealing with the Risk demons.  Following is quite self explanatory.

1. Identify: Use whatever the method, either daily scrum, scrum of scrum, weekly meeting or your instincts to identify the risk. 
2. Access: 
• Probability: I usually use the parameters such as experience of the team, no of components affected and category ( security, non-functional or functional). Some risks are very likely to occur. Others are very unlikely. Establish and utilize a scale that reflects the perceived likelihood of a risk. Depending upon the degree of detail desired and/or possible, the scale can be numeric, based on a percentage scale, such as “20 percent likely to lose a key team member” or based on categories, such as: very improbable, improbable, probable, or frequent. In the case that a categorical assignment is used, the team should establish a set numerical probability for each qualitative value (e.g. very improbable= 20 percent, improbable = 30 percent etc) 
• Impact is the loss if the risk occurs. Delineate the consequences of the risk, and estimate the impact of the risk on the project. Similar to the probability discussion above, the team can choose to assign numerical monetary values to the magnitude of loss, such as $10,000 for a two-week delay in schedule. Alternately, categories may be used and assigned values, such as 1=negligible, 2=marginal, 3=critical, or 4=catastrophic.
3. Plan: All the prioritized risks should be proactively monitored. Following can be used as a guide to plan the actions.
• Information Buying: Perceived risk can be reduced by obtaining more information through investigation. For example, in a project in which the use of a new technology has created risk, the team can invest some money to learn about the technology. Throw-away prototypes can be developed using the new technology to educate some of the staff on the new technology and to assess the fit of the new technology for the product.
• Contingency Plans: A contingency plan is a plan that describes what to do if certain risks materialize. By planning ahead with such a plan, you are prepared and have a strategy in place do deal with the issue.
• Risk Reduction: For example, if the team is concerned that the use of a new programming language may cause a schedule delay, the budget might contain a line item entitled “potential schedule” to cover a potential schedule slip. Because the budget already covers the potential slip, the financial risk to the organization is reduced. Alternately, the team can plan to employ inspections to reduce the risk of quality problems.
• Risk Acceptance: Sometimes the organization consciously chooses to live with the consequences of the risk (Hall, 1998) and the results of the potential loss. In this case, no action is planned.
4. Action: The actions plan on the previous state must be executed. Mitigation action can be in two fold; Risk avoidance or Risk protection. 

(source Laurie Williams 2004)

IF YOU KNOW YOUR RISKS THEN VISUALIZE 

During the sprint or release execution, it is crucial that the PM, SM and the Agile Team are fully aware of how you manage your risks. This can be scaled from the scrum team to a program level. How? The answer is through Risk Burn Down.

Again you can't talk about risk without talking about Risk Exposure.

Risk Exposure is a simple calculation that gives a numeric value to a risk, enabling different risks to be compared.

The picking values can be varied from one team to another.

Risk Exposure = 'Probability of Risk Occurring' x 'Total Loss if Risk Occurs'

Let's take an example.





This risk register is reevaluated at every sprint meeting; its values are adjusted based on the current assessment of the existing and new risks. This would define a new value for the consolidated risk exposure.


Here I am taking some data to plot the Risk Burn Down.




The Risk Burn-down Chart can be created by plotting the consolidated risk exposure across the number of sprints run by the team.

In a nutshell, the burn-down chart represents the status of the risk across the iterations. From a project management perspective, this is an excellent indicator of how the risks are managed and controlled. Similar to other burn-down charts, the ideal burn-down would be a linear decrease of consolidated risk exposure over the sprints.

None of the project or product developments are risk free. So we need to embrace the risk management techniques and get ourselves adapt into one of the proactive techniques.

Happy Risk hunting!!!