Managing Risk on Agile Projects

We’ve Got Risk Management Nailed. Don’t We?

Risk is something we deal with daily. How long before your flight or train do you need to leave the house? Can you make it to work and back before filling up the car? We make conscious decisions about these things knowing that choosing incorrectly could mean a costly flight re-booking or an embarrassing call telling someone you are stuck on the motorway.

I’d be lying if I said I had never run out of fuel or never missed a flight. However, the last time I missed a flight was in 2011 and the last time I ran out of fuel was ten years before that. You might say I’d learnt my lesson. I have. But I also think about the likelihood of missing my train or what I’d do if I ran out of fuel.

Why then are we so bad at managing risks when it comes to projects? You’re only an optimist until you manage your first project, so it can’t be this. Might it be that we are lazy? Or unimaginative? I can’t say for sure, but what I know is that we can do a much better job.

We’ve invested a lot in project management frameworks and these approach risk management in different ways. Prince 2 has a very formalised, robust risk management approach, while Agile addresses risk more through the values of the Agile philosophy. Agile is a great way to deliver projects, software or otherwise, and more and more projects are adopting this approach. I think though, that using an Agile approach we assume we have risk management nailed. When in fact, we don’t. I think that using Agile has left us with a blind spot. How then do we address this?

First, let’s leverage Agile to address the risk management aspects it is good at. The customer might change their mind about requirements. No problem, we’ll change the user stories in the backlog. Priorities. No problem, we’ll change what’s going into the next sprint. Reduced budget. No problem, we’ll build a minimum viable product.

But what about the other risks? A key stakeholder leaving the project. A production environment not being available. A component provided by a third-party not being delivered to specification or on time. Hmm, good question, how do we manage these risks?

Trust in Agile

First, trust your Agile methodology with the type of risks it is good at managing and then worry about the rest. This means you need to understand the strengths and weaknesses of Agile as a philosophy and the strengths and weaknesses of your specific flavour of Agile. Think Scrum, eXtreme Programming, Lean, etc.

Back to Basics

Next you need to think about the risks that will not be implicitly addressed by your chosen methodology. Most projects, especially software development projects, will have a common set of risks. Prior to your first sprint, start with these and build a ‘catalogue’ of risks you can use again and again. Now think about the specifics. A good place to start is by looking at your project commercials or contracts. Pull out any assumptions or dependencies that are listed. Each of these will become a risk. For example, if there is an assumption that a production environment will be available by a certain date, the risk is that this environment is not available. If there is a dependency on your project sponsor appointing a product owner, the risk is that you have no product owner.

Besides the commercial and contract documentation - as these might not apply to an internal project - you can use the business case, project initiation document, business plan, product specification, project brief, or any other relevant document.

Draw out all the assumptions and dependencies, and you’ll have made a good start.

Let’s Get Traditional

Having progressed this far, now build out your risk management plan using a traditional risk management approach. This means assessing and scoring the likelihood of a risk occurring, assessing and scoring the impact that a risk would have, should it occur. Multiplying these two scores will give you an indication of how serious a risk is, in relation to the other risks. You should set a threshold and any risks below that threshold can be dealt with in a less formal manner, such as ignoring them or addressing them as and when they occur. Risks above the threshold will require a plan to manage them.

At minimum, your risk management plan should include:

• An owner for each risk. This is important because if each risk doesn’t have an owner, it won’t be managed.
• How distant the risk is. This helps you prioritise resources and effort.
• A mitigating action or actions to prevent the risk from occurring.
• A remedial action or actions to minimise the impact should the risk occur.  

This risk plan then needs to be reviewed and managed as part of your sprint ceremonies. This is where Agile becomes powerful because you’ll have a daily view on risk, rather than a more traditional weekly view. Risks should be added when they are identified, removed when they are no longer relevant, or updated, as circumstances change.

Risk Equals Money

To make your risk management even more effective, take the basics a step further. Ahead of the project, assign a monetary value to the mitigating actions, that is, the cost of carrying these out. Next, assign a monetary value to the remedial actions. If the mitigation cost is higher or the same as the remedial cost, you can probably deprioritise this risk.

Each of your remaining risks should now have a value assigned to them. The aggregate of these values should then be set aside as a risk management budget. The individual risk values can be tweaked by multiplying the value of the remedial actions by the probability of that risk occurring, with a 1.0 suggesting the risk will certainly occur and a 0 suggesting the risk will certainly not occur. This now provides a weighted value for each risk. These weighted values should be aggregated to provide an overall value for your risk management plan.

You should agree an additional amount of project budget based on this amount. The budget should be set aside for risk management only and should never be used for the functional aspects of the project. If things go wrong, then you have the budget available to remedy them. Alternatively, if all goes well, this risk management budget will be returned to the project sponsor.  

Conclusion

While many Agile practitioners may baulk at using ‘traditional’ risk management practices as part of an Agile project, the two approaches are complementary. You get the discipline of a risk management methodology made more powerful by the principles of Agile delivery.