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.
James Shore added that effective risk management can help a team make solid commitments. He suggested using tools like risk multiplier and burn-up charts for managing project specific risks.
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.
Risk Multiplier
Chance | Rigorous Process | Description |
10% | 1 | Ignore--almost impossible |
50% | 1.4 | Stretch goal--50/50 chance |
90% | 1.8 | Commitment--virtually certain |
Now, to make the commitment, the multipliers would be applied like this
Chance | Story Points | FinishedDescription |
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.
Community comments
It is a waste
by Gary Chia,
Re: It is a waste
by Jack Milunsky,
Re: It is a waste
by Arijit Sarbagna,
Agile risk management
by Mark Anderson,
It is a waste
by Gary Chia,
Your message is awaiting moderation. Thank you for participating in the discussion.
Tracking risks "EXPLICITLY" in Agile is a waste. You do that all the time with standups, review meetings etc. There is no need to track it explicitly.
There is a need only when you are "not" doing the other practices correctly.
Re: It is a waste
by Jack Milunsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree. Risk mitigation is implicit in Agile.
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
Jack
www.agilebuddy.com
blog.agilebuddy.com
Agile risk management
by Mark Anderson,
Your message is awaiting moderation. Thank you for participating in the discussion.
The development KPIs we gain through use of Accurev (www.accurev.com) and properly staging our continuous integration environment (see blog by Damon Poole) are ways we incorporate risk management within our agile process.
Re: It is a waste
by Arijit Sarbagna,
Your message is awaiting moderation. Thank you for participating in the discussion.
I fully agree! As already stated, agile has so many measures in-built, which addresses risks or rather the probability of occurrence of any risks. I loved the statement made above -
"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. :)