How does agile risk management scale? A concept.

What does it mean for your project if an important know-how member of the team fails or if a new IT tool does not meet expectations? How do you recognize as early as possible that things are not going smoothly in the project — and how much does risk management make sense in agile projects? Although some techniques used in Scrum, such as sprint reviews or burn-up charts, help to minimize risk, additional, systematic risk management is advisable, especially in the enterprise environment.

In my current project at a large German corporation, 40 developers and 20 experts are working together in four scrum teams on a complex digitization project — an enormous challenge for the strategic handling of risks! Basically, Scrum does not make any binding guidelines for risk management and accordingly, there are different opinions and approaches in the Scrum community.

Our goal was to develop a model suitable for us that …

• sharpens the view of the risks in the teams
• establishes a common benchmark for risk assessment
• actively minimizing/eliminating risks

Risk management based on SAFe

The risk management concept we developed is based on SAFe and adapts the elements described in “PI Planning”:

• Risk management is firmly integrated into the regular retrospectives.
• Each Scrum team documents the risks according to SAFe standards.
• The risk elimination measures are documented on the basis of the SMART criteria.
• The confidence of the Scrum team members in achieving the upcoming sprint is queried and taken into account, taking into account the current risks.
• A weekly community of practice supports cross-team risk management.
  Stakeholders are promptly informed about the status quo of all risks and the emergence of new risks (group-compatible risk management).
• The risks are visualized on a whiteboard at each team table in the form of the risk matrix known from SAFe in order to keep them transparent for the team throughout the sprint (see below).

What is SAFe?

Agile methods such as Scrum are designed for use in small individual development teams. If several teams work together on large projects or across companies, an extended framework that offers solutions for scaling Scrum is necessary. Dean Leffingwell’s Scaled Agile Framework (SAFe), which combines elements of Scrum, Kanban, and Extreme Programming with Lean Thinking, has proven itself in many companies.

“As Scrum is to the Agile team, SAFe is to the Agile enterprise.” Dean Leffingwell

The use of the framework in practice

Risk matrix according to SAFe

Each of our teams uses a whiteboard for risk management, on which each risk (unwanted state in the future with a certain probability of occurrence) is documented and evaluated. To classify the risk status, we use the ROAM matrix according to SAFe, i.e. the four quadrants “Resolved”, “Owned”, “Accepted” and “Mitigated”.

• “Resolved”
  From the team’s point of view, the risk is no longer a problem OR
  The risk has been eliminated (measures have been agreed in the team according to SMART criteria that reduce the probability of the risk occurring to 0 percent.)
• “Owned”
  Since concrete measures cannot be agreed immediately, a team member is responsible for the risk. For the coming retrospective, the person responsible has the task of developing and presenting suggested measures according to SMART to eliminate the risk. These are then discussed with the team and the further procedure is agreed.
• “Accepted”
  The risk is understood and accepted by the team. However, it is not possible or sensible to eliminate the risk. Examples of such risks are natural disasters or products/innovations introduced by the competition that the company could not have known about.
• “Mitigated”
  Measures have been agreed which contribute to the avoidance and thus to a lower probability of occurrence of the risk. It is important that the team is aware of the remaining probability of occurrence!

Definition of measures according to SMART criteria

We document all risk avoidance or risk elimination measures based on SMART criteria:

• Simple: The measure must be easy to implement.
• Meaningful: The measure must have a specific goal (e.g. eliminate a pain point).
• Achievable: The measure must be achievable (similar to “Simple”)
• Realistic: The measure must be realistic in its implementation
• Trackable: The measure must be traceable (e.g. through milestones, date, etc.)

Vote of Confidence

In the final Vote of Confidence, the Scrum Master asks the developers to communicate their confidence in the achievability of the following Sprint, taking the risks into account. This is done by raising your hand and showing a value from 0 to 5 by stretching out your fingers (0 fingers -> no trust / 5 fingers -> full trust). It’s good practice to accept the sprint commitment if the average score is greater than three. If the value is worse, the sprint planning should be revised and further risk minimization measures should be considered.

If risks were identified in one of the teams or by individual team members that are relevant across the project, they should definitely be discussed in the next Scrum of Scrum! The Scrum Masters bring these risks to the project management and inform the teams about the status.

Conclusion from practice

This approach to risk analysis and the derivation of goals and measures has been used in one of our projects for a few weeks. The feedback from the teams has been consistently positive so far. The concept is particularly popular with management since risks are recognized from the bottom up — i.e. by the members of the Scrum teams –, assessed with regard to the extent of the damage, and minimized directly through suitable risk avoidance measures.

It was important for those responsible that the teams were accompanied during the risk analysis and that there was moderation in order to achieve a common view of the probability of occurrence for each risk and the possible amount of damage. (Experience has shown that certain unrest arises in the teams as long as there is disagreement about the identified risks, the identified goals, and measures.)

I support you in agile scaling and help you to create the right way of collaboration for your agile growth.