Reduce Your Risk Of Failure

by Kelly Waters

The key principles of agile software development help to mitigate many of the common reasons for project failure.

In particular, the incremental approach and active user involvement guard against one of the biggest risks. The risk of building a software product that doesn’t meet expectations. The risk of building the wrong product.

But how does agile software development help you to manage risks that fall outside the development process? The risks that aren’t inherently reduced by an agile approach.

Here I take a look at how you could incorporate a more traditional approach to risk management, within a project that's using an agile approach...

In a more traditional PRINCE2-based project, you would keep a risk log. Typically a risk log would include the following information:

description of the risk
date raised
likelihood - description of its likelihood and rating (1 unlikely, 2 possible, 3 likely)
impact - description of the impact and rating (1 low, 2 medium, 3 high)
mitigation - what could or should be done to reduce the likelihood of the risk?
contingency - what will we do if the risk becomes an issue? What should we be doing to plan for it's eventuality, particularly if it's likely
actions (with dates and owners)
last updated - when the entry in the risk log was last updated and by who

You can keep a risk log in agile projects too. Of course. There are no rules in agile which say you must not use any other management approaches or artifacts in conjunction with an agile approach.

But how do you make something like a risk log more akin to agile principles? And how do we integrate this kind of risk management within the iterative cycles of agile development? Here are some suggestions...

Make it visible. Put it on the wall for all to see. For the team, project manager, product owner, etc to see every day in the daily stand-up meeting.
Make it collaborative. Allow anyone to add a new risk or add comments on an existing risk any time they want.
Make it visual. Put the likelihood and impact in a 3x3 grid, so likely risks with high impact are top right (in red) and unlikely risks with low impact are bottom left (in green). Each risk then gets a score of 1-9, i.e. likelihood*impact.
Make it part of the process. In Sprint (iteration) planning - as well as asking what went well, what didn't go so well, what would we do differently in the next iteration - also ask what could prevent us from meeting our objectives? For the Sprint and for the project as a whole. Facilitate the team's thought process to actively identify risks. Add them to the risk log on the wall.
Include it in the product backlog ('feature' list). If it's appropriate to do something to mitigate a risk and reduce its likelihood, or to prepare contingency for the risk, add the actions to the Product Backlog for the project and prioritise them along with the features. The Product Owner is then taking business responsibility for the risk and its priority relative to features of the product. If a risk occurs before the mitigating actions are reached, this was a knowing commercial judgement about its priority and not a failing of the team to identify or highlight the risk.
Review it daily. In the daily stand-up meetings - as well as asking what have you done since the last meeting, what will you do before the next meeting, and if there anything holding up your progress - also ask each team member if there's anything that could prevent them from meeting their goals. This will encourage a little proactive thought, not just reactive when progress is blocked.
Make it the team's responsibility (to identify and highlight risks). By asking the team to identify risks during planning meetings, and within each iteration. By asking the team to rate the likelihood and impact. By asking the team what could be done to reduce a risk's likelihood. By asking the team what we would do if the risk materialises. However the priority of a risk is still a business decision. It's up to the Product Owner to decide on the priority of a risk, in relation to other activities on the backlog.

In other words, on major projects particularly, make risk management part of your everyday business.

See also:
Why most IT projects fail. And how agile principles help
A sad indictment of the software development industry
10 Key Principles of Agile Software Development
10 Key Principles - PowerPoint presentation