How do Scrum Projects assist with Managing Risk? Agile and Scrum are particularly targeted at reducing Risk. However, this does not mean that Risk to Scrum Projects can be neglected. The Risk Management process described has much in common with a lot of other Risk Management Frameworks. If your Company has embraced a specific Framework, it is suggested that you align with that Risk Management Framework. If you do not have an official Risk Management Framework in place, this is a straightforward process. This process has much in common with ISO 31000. However, there are some differences in the grouping of the primary activities, but not their content.

Managing Risk: Scrum Processes

• Risk Management is an iterative process. This makes it easy to incorporate into Scrum. There are 5 significant Risk Management activities:
• ‘Identify’.
• ‘Assess’.
• ‘Prioritise’.
• ‘Mitigate’.
• ‘Communicate’.

Mitigating Risk – Why and How.

When the Project was initiated, there was a general Vision and objectives. At this point there is an expectation that everything would Work according to the Plan. Applying Risk Management is a bit like being a pessimist. This means assuming that nothing will Work to Plan. You are required to think beforehand about what needs to occur to avoid the Risk becoming a problem.

This action is called a Mitigation, and it is expected to lower or remove the Risk. To put it simply, Mitigation is “Plan B”.

Earlier in the Risk process, risks are identified, Assessed and prioritised. At this stage the Mitigation most appropriate for each Risk is selected. There are generally four kinds of Mitigation, and the choice in each case is determined by the company Risk profile. A conservative and Risk-averse Company will budget for the minimum Risk, while a more entrepreneurial and innovative Company may be prepared to take more Risk.

Managing Risk: Acceptance of Risk.

Not all Risks can be Mitigated. The insurance coverage term “Acts of God” applies here. An earthquake, twister or other natural disaster can not really be Mitigated to any great degree. Likewise, not all Risks will be required to be Mitigated. If the Risk has a low probability and impact, the impact may be accepted and absorbed by the Project.

Managing Risk: Avoidance.

Risk avoidance as a method gets rid of the Risk by avoiding it altogether. For instance, by discovering an alternative action that changes the Risky action. Or having a fail-safe Plan that will start if the Risk happens. Risk avoidance typically requires a high monetary outlay. Companies can not always pay for both Risk avoidance and new Product Development. There will need to be some compromise. A case in point of Risk avoidance is a data recovery site that mirrors your primary hardware site. When it comes to failure, processing swaps over to the remote website. Another example is the “freeze” that banks apply to IT Changes throughout the holiday period, avoiding any Change during peak usage.

Limitation or Control.

Limitation of Risk is a compromise between avoidance and acceptance; some actions are taken that will manage the Risk, should it take place. With Risk Limitation, the Risk is anticipated to happen and there will be some effect. Rather than having a primary and back-up website like the example above, there would just be one site with a daily backup which is kept off-site. In the case of failure, the back-up may take some time. This may impact the Project for a limited period of a couple of hours.

Managing Risk: Risk Transfer.

If you outsource some of your non-core Business, you will recognise this Mitigation type. The placing of non-core Work with an outsourcing service supplier is a form of Risk transfer. While Risk transfer is an excellent technique to decrease Complexity, it likewise removes the capability to manage what has actually been outsourced. Your service provider’s Value chain can become your weakest link if their operation is not as robust as it seemed at the time of outsourcing.

We found these books great for finding out more information on Agile Scrum:

Who Should be Involved in Defining Mitigations.

Where Risks are internal to the Project, they can usually be discussed and validated by the Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team). Where Risks are external to the Project, or need a financial expense, it will be essential to include subject experts such as the design Team and the finance department, even to CFO level if necessary. It is also helpful to include Stakeholders in the Mitigation sessions, as they are then both committed to the Mitigation responses and kept notified regarding what the Plan of action will be. While the Plan would be Communicated to them according to the Risk Management process, engaging them in the Mitigation activity makes them part of the solution.

Preparing the Mitigation Plan.

As soon as Mitigations for all the identified Risks have been discussed and agreed, they should be Documented and a Mitigation Plan must be prepared. Ownership of the Risks, activities and process that will be used in the case of a Risk occurring are consisted of in the Plan.

Risk Status.

Risk Management is not static: a Risk can become more severe or decrease throughout the Project, and this is monitored throughout the Project. The beauty of Agile and Scrum, is that the framework is Risk-based. This lowers the overall Project Risk and makes Risk Management easier. It is only during the Sprint Review meetings that the risks can finally be removed through the delivery and acceptance of the product feature.

How Scrum Facilitates Mitigation.

Agile Development is rapid and short-term, thus minimising the opportunities of a Risk happening. High priority features in the Product Backlog are Prioritised by the Product Owner because they are the highest Risk components. This is due to the fact that there is unpredictability about the Requirement or they are essential to the effective Product design. The prioritised features are only committed to during the Sprint Planning Meeting.

We found these books great for finding out more information on Agile Scrum:

The fact that the Project is completed as soon as possible means that Risks that are either low in impact or low in probability can be accepted, rather than avoided or limited, because the chances are good that the Project will complete before those Risks occur. Scrum Risk Management is therefore simpler and less onerous than Traditional Project Management, although it uses the same techniques.