Agile Risk Management

Sean Robinson
Mar 16, 2015
6 min read

Please note that this no longer represents my view on this subject, but is maintained for posterity.

Risk Management is a part of everyday life, crossing the street or even walking downstairs in the morning carries with it some risk factor. A project is no different. When projects were managed by default by using high overhead techniques such as PRINCE2, risk was an integral part of running a project; they were cataloged, monitored and actively mitigated through the use of logs and registers. Many of us have since abandoned these heavy methods in favour of lighter approaches, such as Scrum or Kanban. However, amid all of the confusion in the revolution, we appear to have thrown the baby out with the bath water. Even now, risk is rarely included as an active element in our practice, and rarely done well. I would propose a new method of managing risk, something lightweight that fits with our de facto practices, but with the rigour of the old guard.

What is Risk?

First, let’s define risk. The ISO31000 standard defined risk as an uncertain event, which should it occur, will have an effect on the project meeting it’s objectives. Notice the lack of connotation here, risk isn’t some inherently bad thing, it’s simply a degree of uncertainty. The message is clear, we should be looking for, and actively managing, all forms of uncertainty.

Risk sits in the middle of cause and effect, some cause may trigger an effect, although we don’t know.

A common risk in a project is late delivery, but what happens if we deliver early? Or if somebody delivers something early to us? Are we capable of capitalising on it? Then there’s employee turnover, this could have quite serious consequences associated with it, but what of we get lucky and have additional resources assigned to the project? Are we able to effectively use them? Scope creep is considered a negative factor, but what about scope reduction? The point is, we spend so much time focusing on what bad things may happen, that we are invariably unprepared for any good. Risk management is about handling both sides of the coin. Risks that carry positive effects are called opportunities, those that have negative effects are called threats.

How do we manage it?

Identify

This is the stage where we start our journey, this could be a workshop, pre-mortem or even just an informal chat towards the start of a new project. The goal is to generate ideas. Be open here, at this point volume is more important than quality. You could use customer interviews, SWOT analysis, brainstorming, whatever works. A nice idea is to keep a checklist of common risk areas, then you can give yourself a starting point.

Assess

Assessing a risk doesn’t need to be some overly complicated approach that you need a doctorate in applied mathematics to understand. It comes down to one thing, severity. The two factors that go into this are usually probability and impact, how likely and how big. Time is sometimes used in conjunction with this to give a temporal facet too, although we won’t go into that here. The easiest way to start assessing your risks is to draw a graph on a board somewhere, draw axis for both probability and impact, and then get everyone to start putting your risks somewhere on the board. Keep it light and flowing. You’ll end up with higher priority risk in the top left, and lower ones in the bottom right.

Now you need a way of determining exactly what you need to be working on, I would suggest using a grid like the one shown below.

Now band the grid depending on your risk appetites and tolerances.

Finally, determine suitable categorisations or actions for each band.

At this point, you know have an ordered list of risks based on severity, with classifications that imply how much energy should be expended in managing them.

Plan

Now comes the tricky part, planning your action. Broadly speaking, there are four ways of managing opportunities and threats.

Threats

Avoid: Eliminate uncertainty by not doing something, or doing something in a different way.
Transfer: Transfer liability/ownership to the client, sub-contractor or third party.
Reduce: Cannot avoid, so action steps to reduce probability or impact.
Accept: Accept the consequences, the required effort to reduce the impact or probability does not justify managing it.

Opportunities

Exploit: Eliminate uncertainty by not doing something, or doing something in a different way.
Share: Share the opportunity with the client, sub-contractor or third party.
Enhance: Take steps to improve probability or impact.
Accept: Accept the risk, the return does not justify managing it.

Making it Agile

One of the most important things to consider here is overhead. We threw out heavy documentation and administrative overhead for very good reasons, the last thing we want is to bring it all back in. We also want something that doesn’t require everybody to go on month long courses to understand. So we’re looking for a process that is lightweight and sits nicely with our existing systems. The key is to manage risk like any other ticket in your backlog, exactly like any other ticket. One of the more common practices nowadays is to have an ‘Agile Risk Board’.

Here, Agile practitioners can use their existing understanding to manage risks on a separate board in their workplace. Risk tickets will go through the same process that would be applied to any story or bug ticket. An example field setup could be:

Now I don’t like this approach for several reasons, chief among which is that this doesn’t encourage us to value risks in terms of other business activities. By having separate boards, the implication is that we split our time managing risks and completing backlog work. Risks cost to manage, and that time should be valued in exactly the same way as our other duties. There is also an overhead issue, Agile teams are used to working with a backlog, it is commonly embedded in their daily practice to keep an eye and update it as required. By introducing a whole new board, you are forcing people to managing two discrete sources. There is also the issue of duplication, the bane of a programmers work.

My proposed solution, and something that I have used very successfully, is to bring risks into your current board. Schedule risks just like anything else, and prioritise them inline with your current tickets. There isn’t a free pass for bugs to supersede stories, so there shouldn’t be one for risks either. Everything is prioritised fairly in order to ensure that work in progress is always of the highest value to the project.

There are several benefits to this approach. It gives excellent visibility of risks without much additional overhead. By embedding itself with an existing process, there is very little to learn, but inherently promotes active management. Perhaps most importantly, it means that risks are judged in terms of business value.

There are, of course, downsides to this. Despite the simplicity of the approach, there will always be a little additional overhead. It could also be very difficult to measure risks in terms of business value. Estimating stories in terms of work or value is still something that many of us find incredibly difficult, introducing another facet into this is going to sting at times. Not an issue with the approach as such, but this requires a new way of thinking; developers and managers alike will need to widen their view of a project in order to spot risks, and will need an appreciation before they can fully buy in.

Overall, this has been one of the most enjoyable and beneficial ways that I have found to manage risk with Agile teams. For me, it’s not too heavy, but gives most of the benefit that I used to get when using the lumbering approaches of old. I’d love to hear what people think, so feel free to get in touch with your thoughts or alternative approaches that you’ve used.