How to cross risk management and Agile?

We continue to talk about the features of the application of Scrum in customized development and in this article I will discuss how to combine 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 it is necessary to adapt classical approaches to risk management, not forgetting the principles of Agile.

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

Work with risks is carried out in several stages, which are depicted in this diagram:
')

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

• SEI Taxonomy-Based Risk Identification - a taxonomy of risks and a questionnaire from the Software Engineering Institute
• MSF Risk Management Discipline Ver 1.1 - A More Lightweight Version of Microsoft Software Risk Categorization

Risks must be visualized so that the whole team (and the customer) knows them and fully participates in their management. The worst option is to make an Excel-file with risks (in the most secluded corner) and with the package to say: "I have this risk in the registry at number 37". The most agile option is to make a board with risks and track their life cycle.

But it is important not to overdo the risks, especially involving the customer to this work, because it may seem to the team that the project consists of potential problems alone. Very clearly, this situation is manifested in teams that have not done a detailed risk analysis before, but just blindfolded, attacked the rake.

Let's take a closer look at the stage of analysis and prioritization of risks. We agreed to make the process as simple as possible, so I suggest finding a middle ground between qualitative and quantitative risk assessment. Quantitative estimates and mathematical modeling are fairly conventional 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, while not using monetary valuations:



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 related to the operational monitoring of risks and the correction of consequences are very convenient to carry out on daily stand-ups: now the team will deal not with virtual problems, but with specific risks.

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

Author: Boris Volfson - Head of Softline Development Department