In Agile software projects, risk management seem to have taken a back seat. Due to the iterative nature of delivery, overhead of risk management may outweigh the benefit of doing it.

If you are managing a big project involving multiple teams/sprints, I suggest doing risk management at two levels – Project level and Sprint level.

Risk Management is a slightly convoluted topic. Let’s first get some basic definitions out of the way.

Risk: It is a potential event that can impact your project. A risk can be positive or negative, although, in general lingo risk is mostly associated with an event adversely impacting the project outcome. For example, if your project uses Microsoft Azure, then Azure team forgetting the annual certificate renewal (which resulted in Microsoft Cloud outage for two years in a row) will be considered a risk to your projects for next few years at least!

Issue: When a risk has materialized then it has become an issue. Well, if Microsoft again forgets to renew this certificate then it is not a risk anymore, it has become an issue because now you cannot access resources on the cloud until the certificate is renewed.

Mitigation: This is action that you can take to reduce the impact or probability of the risk. There is no mitigation that you can use in the above example.

Contingency Plan: This is the action you will take if the risk materializes, e.g. team will use their local machine environments in case Microsoft Cloud becomes unavailable again!

Risk category: Risks come in different categories e.g. Business Risk, Infrastructure risk, Budget Risk, Resource Risk, Environmental Risk, Compliance and Regulatory risk etc. Knowing high level risks impacting your industry will help you track appropriate risks for your project.

  1. Business risks is the risk of building a product/service that nobody wants, or will you use.
  2. Infrastructure risk may include acquisition of hardware, computers etc. needed for project development.
  3. Budget risk is the risk of running out of money before the project finishes.
  4. Resource risk may include acquisition or retention of resources
  5. Environment risk is any risk to the environment due to the production process, use or disposal of your product e.g. disposal of electric batteries has major environmental risk.
  6. Compliance and Regulatory Risk covers any risk associated with getting compliance and regulatory approval required for the product launch.

Risk Response Approaches:

These are the various approaches that you can take to handle risk. It includes:

Avoidance: This means deciding or taking an action to eliminate the risk. E.g. If there is a risk in hardware acquisition in your data-center, you can eliminate that risk by moving to the Cloud.

Mitigation: This means you are taking an action to reduce the probability or impact of the risk e.g. instead of waiting for the new machines to arrive, you may decide to use the existing machines in the data-center even though it may not be optimum for the project.

Acceptance: You accept the risk because either its part of doing the business or something completely outside your control e.g. risk associated with Azure certificate expiry can only be accepted unless you plan to change your cloud provider (which will be a much bigger decision).

Transfer Risk: This means transferring the risk to another entity e.g. risks associated with upgrading to the new software package can be transferred to an external company if we buy the upgrade service along with the upgraded software!

Now the academic stuff is out of the way, lets focus on what practical steps you can take to manage the risk, what artifacts will be needed, who will create and maintain them etc.

Project Level Risk Management is the traditional way of managing risk. You can create a risk register and keep it updated as the project progresses. Below is a sample project register:

We have used a scale of 1 to 10 for Severity and Probability, with 10 being the highest for both. Risk rating is product of Severity and Probability, so a risk with rating 95 is almost certain to materialize.

In the above example of Engineers not getting laptops in time, we have marked Severity as 10 because it’s a work stoppage scenario and Probability as 3. Probability of a risk is joint guess by the team on the likelihood of this risk materializing.  This risk gets a rating of 30 which is on the lower side.

So, what is the advantage of maintaining the above register? Well, there can be infinite risks associated with a project. You can agree as a team that you will track risks which are above a certain threshold. TPM can create the above register with team’s input, update and maintain it as the project progresses. Management and Leadership is interested in knowing the risks associated with a big initiative

Agile Risk Management is done at the sprint level. Project level risks can be an input to the sprint risks. Below are few artifacts that will come handy for agile risk management:

Risk Radiator Board: This is a simple board where anyone perceiving any risk to the sprint an add an entry. This can be a physical board or a virtual board. Information radiators are a great source of information collection, keeping it fresh in the memory and stimulating ideas and conversations leading to mitigation’s etc.

 

Risk Census: This is a collection of risks, their impact (in days), Probability and Exposure.  Risk impact is the loss of productivity measured in the lost number of days if the risk materializes. Probability is the likelihood of the risk happening. Risk Exposure is the product of Risk Impact and Risk probability which gives us a measure for risk tracking.

Above table can be created as part of the Sprint Planning Meeting and then TPM can update this daily and track it as part of the Risk Burn-down Chart. In the chart shown below, risk is decreasing (almost linearly) by the day as we proceed into the sprint ideally reaching zero by the end of the sprint.

If the substantial risks remain till the end of the sprint, then the team may need to take explicit work to reduce that risk in the upcoming sprint.

Agile risk management may not look very valuable due to the iterative nature of delivery. Completely foregoing risk management may be an oversight. A simple risk radiator board, risk census and risk exposure burn down graph maintained by TPM should be enough to cover your bases for the sprint.

Risk Management is one of the core areas of project management. Risk management separates seasoned TPMs from the crowd. When you think about project risks, collaborate with the team to come up with a comprehensive list, maintain and update them regularly, you are increasing the chances of your project success significantly.

Join the discussion below and let us know how have you been managing risks in your projects!