Recently, I came across the following Google group discussion about risk management in Scrum. Even though it’s likely that an agile novice posed the question, it’s clear to see that people place a heavy reliance on methodologies that are supposed to solve all of our problems.
Scrum does not have any specific risk-management practices as compared to the PMBOK. However, everything you do in Scrum—as well as any other agile method—will help you identify risk at an early stage. The only tool that you need is your ability to listen well.
Now let’s explore some agile practices that can help you identify risks.
Standup meetings are a great place for team members to identify and share project risks. For example, when your team is busy answering the three questions, make sure you notice whether or not one of the tasks that was supposed to have been completed is delayed; from this you will know if there is a risk in the timeline.
If someone raises a blocker during the standup and the team feels it cannot be mitigated easily, you can consider that a risk to the delivery.
Retrospectives are another great platform to identify risks. Keenly listen to the responses to the four questions during the event; they can reveal hidden project issues. For example, if you consistently see a recurring pattern about team unhappiness or friction within the team, it is quite possible that this could lead to attrition. Attrition is one of the major risks in software projects.
Sprints or short iterations expose the risks associated with schedules. If your teams are unable to integrate or test properly, it is an early indication of risk. This integration issue could be due to a lack of infrastructure availability, skill, or time to complete the integration testing.
Going back to the original Google discussion, someone recommended that a person designate stakeholders to identify the external risks and teams to identify the internal risks. I somewhat agree with this approach. The problem is that this type of team segregation leads to passing the buck. I believe that risk identification is everyone’s responsibility. If the team members observe a risk at the organizational level, they should be encouraged to speak up rather than waiting for external stakeholders to bring it to the table.
I’ll leave you with a very good review of different risk-identification strategies using a variety of methods. For example, I have come across people using agile-risk boards that display known risks. Teams also can make use of prevention, detection, and response boards; the two-by-two matrix of risk versus value mapping is the most popular type of these boards.
