In traditional waterfall model, risks were usually managed by using project risk management frameworks. Nowadays, there is a kind of lack of formal risk management techniques in agile software development methods. Agile models claim to be risk-driven. By nature, due to its core concept, its iterative approach enables continuous attention to risks and the risks can be reduced by different practices like continuous software integration and early validation. Unfortunately, in reality, the agile model implements only a few risk management practices.
This situation lead to different actions, and one was to obtain the opinion of different project managers involved in managing different projects all over the world. We will discuss a little bit about an interesting survey that was taken quite recently.
Risk management is the discipline of identifying, monitoring and limiting risks. In ideal risk management, a prioritization process is followed whereby the risks with the greatest loss and the greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled in descending order.
Effective risk management involves:
Identifying the risk
Analysing each risk to determine its exposure (severity of impact)
Prioritizing the identified risks based on their exposure
Creating action plans (responses) to deal with the high-priority risks
Risk management (RM) in agile process is similar to the conventional Risk Management approach with slight deviations.
I would start the discussion by trying to find a response and clarify the following two questions:
Does this mean risks need to be monitored at iteration level only? The answer is "No".
I would say that Risk Management in agile needs to be done at two levels, Project level and Iteration or Sprint level.
Project level Risk Management process is done at broader level, taking into consideration the whole project and its requirements
Iteration level Risk Management process is done at the iteration level encompassing the details of the iteration
These two processes seem to be separate, but they go hand in hand during the whole project execution.
It is required to understand, identify, track, monitor and mitigate the risks at both levels. Project Level Risk Management process would provide inputs for the Iteration Level Risk Management process. Bear in mind that not all of the Project Level risks will be part of all the iterations. Some of the risks could be different and others may be unique for a specific iteration alone. Risk Monitoring happens during the iterations and Risk review sessions happen between iterations. It is strongly required to know where the project and iterations are in terms of risks management.
I believe every Project Manager, Scrum master and the team, should understand the requirements to arrive at the major risks that the project would face. Most probably, creating a checklist (a sample one can be found below) that would help in identifying potential risks, curtail them in the initial stages or plan for mitigation of the same, would bring huge cost savings in time.
Risk Management checklist created prior to a meeting can be brought to the meeting to help facilitate the identification of risks. During the meetings, all the risks details are identified, discussed and consensus is reached on the actions items for addressing the risks. Project Risk Register or Iteration Risk register are created and shared within the team, which are referred and updated during the course of the project or iteration.
Ownership and maintenance of these artefacts lies with the Project Manager/Scrum Master.
Project Level Risk Management process involves Risk identification, Planning, Monitoring and closing activities at the end of the project. Each one of the step has it significance which is explained below.
Typical Risk Management activities at the project level are as below:
At the beginning of the project, risks for the project are identified in a broader perspective. Check list (if created) would be of help in the risk identification process.
During the planning session, mitigation and contingency plans are put forward for the identified risks. Risk register is created at project level by the Scrum Master / Project Manager which is referenced by the team as required. This is done at the beginning of the project only. Project Risk register is updated during the course of the project.
All the risks identified earlier are reviewed and monitored between the iterations of the project. Risk Register is updated for the risks which are closed and any new risks that are identified along the way of the project. This information is then used in the iteration level discussion.
Update the risk register with details of what was done when the risk has been confronted during the course of the project. This would be a good reference for future projects. Ensure that the best practices and lessons learnt are created and shared.
Below can be seen the Risk Management Process for projects executed in more Agile environment
Iteration/Sprint level Risk Management process begins right after the initial Project level Risk identification and planning process. During the iteration level process, Risk Management involves multiple steps. There are broadly two Risk Management processes for an iteration which are executed at Identification & planning - at the START of the iteration and Monitoring - during the iteration.
At the beginning of the iteration, Risk Management meeting is conducted. This involves various steps like Understanding, Identifying, Analysing, Prioritizing and Mapping. Each step has its own significance. This brainstorming discussion would require 2 to 3 hours, involving everyone in the team. Inputs from the project level discussion may be taken as inputs for this discussion.
Each step is elaborated below:
Understand: The team should clearly understand the user requirements, both functional and non-functional. Requirements understanding would be very helpful in the risk identification process of the iteration.
Identify: Once we have an initial draft of the product backlog, with a good understanding on the requirements, the team could proceed with the identification process. During the session, each team member should identify any potential risks. There are many ways to run this session, but a simple and efficient way would be to proceed similarly as in identifying stories in the backlog, by using sticky notes. As a best practice, neither questions should be asked nor should discussions happen during this session. Why this? Because this should be a time boxed session without overcome time.
Analyse: This time, the collaboration within the team will play an important role. Each identified risk is analysed and grouped into logical categories or areas: e.g. infrastructure, process, third parties, etc. Along with this process, each risk is rated (it doesn't matter really the scale, but it should be kept simple). Once all these are completed, points/rating for the risks grouped, they are counted. Instead of points or ratings, another possibility would be to assign probability and impact scores.
Prioritize: Once the totalling of the points/ratings for each group is done, they are ordered in the descending order, with the risk group which has the highest risk rating topping the list. For the iteration, take the top 3 risks groups and refer the rest of the risks groups for future debates. When new iteration is executed, the previous version of the risk register (updated during the entire previous iteration execution) is checked to see if some risks are still present. The same process will be repeating until the end of the project.
Map: Mapping is a quick exercise which is done just before kick starting the execution. Top 5 risks identified are mapped back to the backlog/requirement. This would be essential in keeping a close watch when the requirement is being executed. If there is no requirement/backlog, create one. Now create an iteration risk register with the mitigation plan or the risk response plan for each of the risks identified. This is going to be reference point for the team during the course of the iteration. This document is updated during the iteration execution cycle.
The picture below shows typical Risk Management Process in an iteration, depicting all the steps involved:
Monitoring is a key of Risk Management. This happens during the iteration execution. Team responds and acts to the risks as and when they come up during the execution of the project/iteration as per risk register. Scrum master/Project Manager keeps a track of each risk for the iteration. In case the deferred come up as a risk during the iteration, it would be taken up as part of the next iteration. No time should be wasted on the deferred unless they become crucial to be addressed as part of that iteration.
Last year, different surveys took place all over the world having involved different project managers working in different big or small companies. Recently, I found out an interesting survey that took place on East Europe, having involved around 70 project managers, with the objective to find out the current practices in agile project management with regards to risk management.
The results of the survey:
• 67 % of respondents review the project risks on weekly basis.
• 87 % of respondents stated that the project manager is formally responsible for managing risks.
• 27 % of respondents stated that also the product owner is formally responsible for managing risks.
• Respondents were asked who primarily identifies the risks. The project team members
(80%), the project manager (67 %), the development team member (40%) and the scrum master (40%).
• 73 % of respondents use a risk log or risk register to document and maintain risks.
The rest of respondents 27 % use different techniques or don't document risks at all.
Respondents were also asked what risk attributes they document and keep watching. Please check the results on the below graph.
Respondents were also asked what scrum meetings are used as support to discuss the risks with development team. Please check the results on the below graph.
There is a lot of useful information and other details that could be added in terms of specific instruments that could be used to perform the identifications, ranking/rated (based on qualitative and quantitative customized indicators) and tracking of risks during the sprints executions (see Risk Burndown Graph based on counting all risks exposure).
Even though using Agile methodology reduces risk in early phases of software development, we should also consider the idea that there is a demand to start thinking about making more room to risk management on a more formalized way.
"Risk is idle work, not idle workers" - Ken Rubin
Risk Management in Agile Model - Monika Singh & Ruhi Saxena
Project Risk Management model based on Prince2 and Scrum Frameworks - Martin Tomanel and Jan Juricek
Three Key Agile Risk Management Activities - Ken Rubin
by Diana Muntea
