Agile Risk Management
Risk management is an activity directed towards assessing, mitigating and monitoring of risks. Many Agilists believe that the process of risk management for Agile projects is not significantly different from the traditional projects. Though the process might be a bit lighter in Agile, however, the steps of finding, sifting, sorting and creating resolution plans for risks remains close to traditional projects.
Mike Cottmeyer suggested that, Agile methodologies are better in identifying and mitigating risks. According to him,
Agile is so effective at managing risk because risk management processes are built into the very fabric of how we run the project.
There is an implicit understanding that risk is EVERYWHERE on a project. Risk cannot be contained in a risk list. Risk cannot be mitigated in a team meeting or a periodic risk review session. Dealing with risk has to be an obsession. Our mitigation strategies don’t live outside the project, but influence the very nature of how we structure and plan our work.
He further classified risk into three categories
- Business Risk – Deals with delivery of the project with the promised business value.
- Technical Risk – Deals with the feasibility of a technical solution within the time and cost constraints.
- Logistical Risk – Deals with assumptions regarding people and infrastructure.
According to Mike, by virtue of the fact that Agile encourages frequent delivery, constant inspection and adaptation, it inherently is risk management.
However, not everyone agrees that Agile inherently addresses risks.
Jurgen Appelo suggested that more often than not, there is a lack of focus on risk in Agile projects.
According to him,
Risk Management is part of Prince2, part of PMBOK, and part of the CMMI, but you don't often see it addressed explicitly in books on agile methods. I think that's strange.
He also mentioned that, often project managers dig themselves deep into the project and miss the forest for the trees. This leads to a severe lack of focus on risk management.
Risk multipliers account for common risks, such as turnover, changing requirements, work disruption, and so forth. These risk multipliers allow you to set a date, estimate how many story points of work you'll get done, and be right.
James suggested the following risk multipliers for a rigorous process where velocity of the team is constant and the stories are 'done done' at the end of the iteration.
|50%||1.4||Stretch goal--50/50 chance|
Now, to make the commitment, the multipliers would be applied like this
|10%||140 (140 ÷ 1)||Ignore--almost impossible|
|50%||100 (140 ÷ 1.4)||Stretch goal--50/50 chance|
|90%||78 (140 ÷ 1.8)||Commitment--virtually certain|
According to James,
This allows you to make commitments to stakeholders and executives. "We are virtually certain to finish 78 more points by our release date, so we're committing to delivering features A, B, and C. We have a 50-50 chance of completing 100 points, so we're planning on features X, Y, and Z as a stretch goal."
Thus, risk management is an integral part of any Agile project just like traditional projects. The key is give it the desired focus, mitigate it efficiently and make commitments based on it.
It is a waste
There is a need only when you are "not" doing the other practices correctly.
Re: It is a waste
Although the article sort of focuses more on date risk than any other types of risk. I am personally not a big fan of risk multipliers. Rather if the team can reach steady state velocity that should be good enough and velocity should already contain risk in it. Given steady state velocity, it's pretty easy to extrapolate a ship date.
My 2 cents
Agile risk management
Re: It is a waste
"There is an implicit understanding that risk is EVERYWHERE on a project. Risk cannot be contained in a risk list. Risk cannot be mitigated in a team meeting or a periodic risk review session."
I have been associated with Agile practice for over 5 years now & this is an acknowledgement of this statement. :)
Todd Montgomery Dec 19, 2014
Juergen Hoeller,Stéphane Nicoll Dec 18, 2014