Risk Management for Agile Projects

This is the second article I translated for InfoQ.com. It is a challenging one because risk management itself is a very broad topic, and honestly I am not very good at it. Thus, I spend quite some time reading different articles, from the traditional to agile communities before I translated this article.

The very first thing about risk management is to understand what risk is. It is a very common misunderstanding where people mixed "risks" with "problems". "Problems" are certain to happen while risks involve probabilities. SEI provides a very good description on what risk is and what are not risks, and further divided into continuous risk and non continuous risk.

* Non-Risk, a certainty - it is a problem.

* Continuous Risk Management, risks are assessed continuously and used for decision-making in all phases of a project. Risks are carried forward and dealt with until they are resolved or they turn into problems and are handled as such.

* Non-Continuous Risk Management, risks are assessed only once during initial project planning.

SEI also provides a concrete (but heavyweight) continuous risk management framework. In the Agile world, the iterative nature of the project already provides a framework to manage risk. These activities include, daily standup meeting, sprint planning, release planning, and project retrospectives.

Michele Sliger proposed a structured approach for risk management. This includes the following steps:

Risk Identification - the whole team does this exercise on an iterative basis. The results are recorded on white boards or flip charts.

Risk Analysis - qualitative analysis using judgment, intuition, and experience in determining risks and potential losses. Short development cycles and constant reviews in Agile, make this feasible and effective. This is different from traditional projects where quantitative analysis is done and numbers are assigned to the damage which can occur.

Risk Response Planning - entire team participates in developing options and actions to reduce threats.

Risk Monitoring and Controlling - risk is monitored and controlling strategies are discussed at the end of each iteration. Risks are monitored on a daily basis too by using information radiators.

It is good to have a structural approach rather than thinking what to do when there is any potential risk. However, mandating such steps in each project would easily lead to wastes, especially if the team sees no risks ahead. So even with structural approach in place, it is down to the team/stakeholders to decide on whether to put this exercise in place.

Barry Bohem at USC proposed Incremental Commitment Model, where they have "risk driven anchor point milestones" to decide the next step:

* The project can proceed if project stakeholders think the risk level is acceptable.
* If the risk level is acceptable but risk management plan does not meet its needs, extend this part of work and review it afterward.
* If the risk level is low, and the project can proceed.
* Terminate the project if the risk level is too high.

I wish I could read and write on the Incremental Commitment Model very soon. It looks interesting because Barry Bohem has been developing software development models for very long time and ICM is one with the most Agile elements inside. I believe it is interesting to learn the mix between Agile and the heavyweight methodologies.

The second of the article discussed the responsibility of risk management. Although there seems to be different view existing, I think what Ron Jefferies said is correct. Product Owner is responsible for risk management since he/she is responsible for ROI.

It makes the issue clear to all the stakeholders. No one can deny or push the responsibility within the team when there is a clear candidate who should be responsible. More importantly, although PO is responsible, the team needs to assist him/her to achieve the goal. Being not responsible is not the reason for keep hands off completely.

Share with: