How to cross risk management and Agile?

We continue to talk about the features of using Scrum in custom development, and in this article I will tell you how to cross risk management and Agile.

In custom development, there are additional potential problems associated with the customer and his business, so risk management becomes critical. Traditional Scrum does not contain such a discipline, so you need to adapt the classic risk management approaches, not forgetting the principles of Agile.

Although there are no distinguished management practices in Scrum, it should be noted that like any iterative and incremental methodology, Scrum significantly reduces risks by receiving an early feedback from the customer. Scrum also has a very good practice of conducting retrospectives at the end of the sprint, it will help to develop a reaction to risks, but unfortunately reactive, after the risks have been realized.

Risk management is carried out in several stages, which are depicted in this diagram:


The first brainstorm on risk can be included in the zero sprint (by the way, it can be carried out in the form of an innovative game Speed ​​Boat), and then each sprint to conduct additional analysis and develop countermeasures. I note that countermeasures should be precisely preventive, it turns out cheaper :) But in no case do more than necessary, strictly observing the principles of KISS and YAGNI . Representatives of the customer can also participate in the brainstorming, voicing their vision of possible problems.
To stimulate a brainstorming session, I highly recommend using one of the following risk workshops:

• SEI Taxonomy-Based Risk Identification - Risk Taxonomy and Questionnaire from Software Engineering Institute
• MSF Risk Management Discipline ver 1.1 - a lighter version of software risk categorization from Microsoft

Risks must be visualized so that the whole team (and the customer) knows them and fully participates in managing them. The worst option is to create an Excel file with risks (in the most secluded corner) and say, "I have this risk in the registry under number 37, with a fakap". The most “adjuvant” option is to create a risk board and track their life cycle.

But it’s important not to overdo it with risks, especially involving the customer in this work, because he and the team may think that the project consists of some potential problems. This situation manifests itself very clearly in teams that had not previously conducted a detailed risk analysis, but simply blindfolded stepped on a rake.

Let's dwell in more detail at the stage of risk analysis and prioritization. We agreed to make the process as simple as possible, therefore I propose finding a middle ground between a qualitative and quantitative risk assessment. Quantitative estimates and mathematical modeling are a rather arbitrary thing and it is necessary to understand well the properties of the constructed model.

We take only three gradations to assess the likelihood and threats (how much damage it will bring) of risk, and we will not use monetary estimates:



Of course, maximum attention needs to be paid to “red” risks, not only are they most likely, but the damage from them promises to be maximum.

Activities associated with operational monitoring of risks and correction of consequences are very convenient to carry out on daily stand-ups: now the team will operate not with virtual problems, but with specific risks.

As for Lessons Learned, retrospective is just perfect for this. I just note that these lessons and best practices also need to be distributed between teams, for example, on Scrum of Scrum.

Posted by Boris Wolfson - Head of Softline Development