High voltage risk!

High voltage risk!

The difference between the classic and Agile approaches to risk management boils down to a few serious dichotomies. The first is that classic methods tend to be project-manager driven, while Agile processes involve and hold the entire team responsible. Second, while I agree that there are always shades of gray, Agile risk identification and management is built on the continuous re-planning process that is intrinsic to Agile rather than being event/review driven (e.g. phase gates or defined review cycles) which is more the norm in classic project management.

A core mechanism to ensure that risk management is a continuous process is by making risk management part of how the team works and that they get value from the activity. Start by writing risks as a type of user story. Like any other user story, risks will then be reprioritized and planned (when needed) as part of the standard Agile cadence. Agile techniques such as daily standups, demonstrations, retrospectives and sprint-planning activities provide a platform for monitoring and controlling risks. The built-in feedback loops which each of the techniques include act as a safety net to ensure “eyes” are continuously looking at what is happening and what will be happening. The Agile processes, by continuously evaluating risk, allow projects to avoid spending significant time analyzing risks that are not on the horizon, while making it very difficult for a typical risk to sneak up on your project.

Risks tend to fall through the cracks when projects or organizations stop using one or more of the typical Agile techniques and don’t replace them. An example I saw recently was an organization that stopped doing demonstrations at the end of sprints. Despite guidance from the product owner about what was needed and would add value, not all stakeholders were served. When the project was delivered it could not be released. A new release of the product had to be delayed, reducing revenue for the quarter. Layoffs were used to make up the revenue miss. Also, no one had planned for the required rework that was needed to get the project to a point where it could be released, which in turn impacted starting the next set of projects.  As a result the whole project portfolio was impacted.

There are several approaches I use to manage risks in Agile projects. Over the next two days we will describe two ways integrate very nicely into standard Scrum techniques. Both are built on the work of others with tweaks that have been found to be useful. In both cases, I suggest that you customize based on the needs of your project or organization.

The first is an approach popularized by Michael Lant[1].

The approach described below should be started at chartering and refreshed as part of each planning exercise.

  1. Identify Risks: Brainstorming can be used to drive out possible risks or when added structure is needed (a larger or more critical project) I have leveraged SWOT Analyses. I strongly suggest capturing the identified risks as user stories (color code if helpful).
  2. Classify Risks: Classifying risks using a simple taxonomy helps the team ensure that they scan the horizon with due diligence.
  3. Quantify Risks: Quantify each risk story based on the impact if it were to occur. I suggest using a simple scale of one (low) to five (high), representing either business value or days that would be required to fix the problem. Secondly, rate the likelihood of the risk turning into an issue, again using a simple one to five scale.
  4. Rate Risks: Rate each risk based on impact and probability. A risk with a high impact (5) and a high probability (5) would equate to a 25. The risks that are high impact and high probability are immediate and critical. An example of the matrix and response guide is shown below. When you multiply the impact and probability, you are calculating what is known as the Composite Risk Index[2].Untitled
  5. Untitled2Act:  It is time to act. The matrix and response guide are tools to help guide your response; however, any action requires thought.
  6. Repeat the process as needed!

Never forget that risk management is a team activity. Perform risk analysis as part of chartering and then again during each sprint planning session.  The goal is to leverage the wisdom of crowds that can be generated by the team.