Agile Risk Management

What Is Risk Management?

Steven Thomas wrote a very elaborate and valuable post about agile risk management where he defines risk management as follows.

Risk management is about identifying, addressing, and eliminating sources of risk before they become a threat to the project.

He identifies the following areas:

• Risk identification – make a list of the risks that threaten the project
• Risk analysis – assess the likelihood and impact of each risk
• Risk prioritisation – identify the significant risks based on likelihood and impact
• Risk-management planning – plan how to deal with each significant risk
• Risk resolution – execute the plan, i.e. deal with each significant risk
• Risk monitoring – monitor execution of the plans to deal with each significant risk and continue with risk identification

Is There a Need for Agile Risk Management?

Risk management is an important part of both PMBOK/PMI and Prince2. Most agilists on the contrary find separate formal risk management in agile practices unnecessary, as agile inherently addresses risks and mitigates them continuously.

As Mike Cohn states “The short iterations, single-minded focus on working software, heavy emphasis on automated tests, and frequent customer deliveries help teams avoid the biggest risk most projects face—that of eventually delivering nothing. So, it is not surprising that many agile projects forgo any form of explicit risk management. To put it in risk management terms, for these projects the likely savings from explicitly managing risks is outweighed by the cost of explicitly managing risk.”

Nevertheless in an agency-client context, some lightweight risk management practices can bring your agile process to another level. Because of the nature of the relationship between an agency and a client, information often has to be transferred between several stakeholders. This often causes a loss of information on how risks are addressed in a project (an example of transportation as waste in lean terminology).

So what could be a minimum viable way of risk management for digital production in agencies?

Agile Risk Management Tools

Mike Cohn introduces a few possible tools in his article on agile risk management.

The Risk List

How does this work?

• First, build a list of potential risks during sprint planning.
• Rate likelihood and impact on a scale of 1 to 3 or 1 to 5 (low to high).
• Calculate exposure by multiplying likelihood by impact. The higher the exposure, the higher the priority of the risk.

exposure = likelihood x impact

In the example risk list below, the exposure of risk 3 is the highest, so this risk should be addressed first.

The team now can choose what the threshold is for risk to be addressed. As soon as a risk goes above that value, resolutions have to be defined.

These can be added to the backlog as separate stories in case they require development. If they are rather externally oriented, and are for example external impediments to be removed by the scrum master, they don’t have to be added as stories.

Finding the right resolution to a risk is the tricky part. Key is to look for the actual risk driver (for example by using root cause analysis techniques such as 5 Whys or Fishbone diagrams).

The Risk Burndown Chart

As soon as you have a risk list with resolutions, you can plot progress on a separate risk burndown chart. It will give you a lot of interesting information during a project. If you have some time, take a look at this talk by the guys from LeadingAgile on this subject.

To give an example, when you take a look at story point burndowns A and B, B seems to be progressing best. (the horizontal axis represents time, the vertical axis represents storypoints or exposure points)

However, when you plot the exposure points on a second burndown (in this case blue), the combined graph will give you a lot more information.

In case A, the team has focused first on high risk mitigating stories, which slowed down their initial velocity, but limited risk significantly. Whereas in case B, the team is focusing on getting the easy stories out quickly, without addressing the risks in the project.

So When Should I Use Agile Risk Management Tools?

The risk list and the risk burndown can be extremely valuable in an agency environment in two ways.

First of all, it forces your team to think about risks and make them explicit. Risks are given a name and progress on how they are addressed is measured and made visible.

Secondly, it gives you tools to communicate with your client about how risks are being managed and how they can help mitigating these risks, especially when the driver of the risk is within control of the client.

Give them a try, and let me know what your learnings are.