Managing Risk with Scrum

Posted by Vikas Hazrati on Jul 29, 2008 08:44 PM

Community

Agile

Topics

Agile in the Enterprise

Tags

Risk,

Management,

Scrum

Risk management deals with reducing the probability and impact of adverse events on a project. Agile software development, due to its iterative nature, implicitly makes risk management a part of the project life cycle. Members of the Agile community discussed whether explicit risk management is required, the ability of Scrum to manage all types of risk and who should do risk management.

Michele Sliger suggested that in Agile software development risk gets addressed all the time as a part of daily stand-ups, iteration planning meetings, release planning meetings, retrospective and review meetings. However, she suggested a structured approach for managing risk. The steps included,

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.

Ron Jeffries noted that risks are not blocked items, instead they are on the Scrum master's watch list, as a note for things which could go awry. According to him, risks could be of various forms like content not fabricated, new/unfamiliar technology, geographically dispersed team, interdependence with another project, etc. A Scrum team could sort stories by value and risk and work on the risky stories long enough to correctly identify and mitigate the risk. The risk should be added as a story on the backlog and addressed.

Michael James suggested that a software development process like Scrum takes care of risk early in the project life-cycle. It provides various avenues like daily stand-up, sprint review etc where risks can be brought forward and resolved. According to Michael, Scrum does not require a risk register to be created, however, the risks could be managed by the team on a periodic basis.

On a different note, some Agilists believe that Scrum cannot help with risks which are external to the project. It can help with risks related to change in requirement, lack of communication and under performance by team members. However, risks which are external to the project need more than Scrum to be resolved.

Paul Hudson echoed similar thoughts on the Scrum development group. He suggested that though Scrum can handle most of the risks in a project, however, risks which cannot be handled at a team level cannot be handled with Scrum. He gave examples of some risks like lack of understanding of Scrum at the customer, third party products don’t work as expected, external factors which the project depends on won’t happen in time, data loss or corruption in team systems, customer doesn’t speak with one voice, customer representatives have personal agendas that conflict with project goals etc. in support of his point.

Another strongly debated question in the community is 'Who should be responsible for managing risk?'

According to Michele Sliger, the entire Scrum team owns risk management and they are responsible for mitigating it together.

In a discussion on the Scrum Development group, Ron Jeffries suggested that in 'Scrum terms' it is the product owners responsibility to manage risk. Some members agreed with Ron that the product owner is the best person to decide which risks need to be mitigated, since he understands the business best. The product owner can take inputs from all members of the team but the ultimate responsibility lies with him. Peter Stevens added,

As chief bill payer, the P-O is directly interested in mitigating risk. The Scrum Master and Team should/will help the P-O optimally prioritize the backlog. But since ROI is the responsibility of the P-O and the consequence of risk is cost, it is the P-O's responsibility.

Other members of the group suggested that risk management is a team responsibility and everyone on the Scrum team has to work collaboratively to resolve risks.

Thus there is a difference in opinion on whether all the risks can be managed by Scrum and whether risks should be explicitly managed. Most members of the Agile community agree that project related risks can be managed well with Scrum however, there is a disconnect when the risks are external to the project. Similarly, there is no consensus on who owns risk management. There seems to be a strong indication towards the product owner, however some Agilists believe that risk should be managed by the team as a whole.

1. Back to top

   The team already has a lot to worry about already

   Jul 31, 2008 3:49 AM by Eelco Gravendeel

   I understand why it would be good if the team handles most of the risk management. However; in my experience the team already has their hands full on managing impediments and just delivering value added work. In many cases therefore you just can't expect the team to completely manage all risks. You can expect the team to handle any "technical" risk, since that might impact sprint outcomes directly. Team superseding risks however is something a team normally doesn't want to be bothered with and will expect some management level person to handle, e.g. the Product Owner.
   
   (I also blogged about risk management vs impediment management some time ago)

   Reply

• Older >