The Naive Notion that Agile Mitigates Risk

Top 5 Ways Agile Mitigates Risk is one of those posts that's correct in what it says at the detail level - more or less, but not right in principle.

Agile Mitigates Risk - is not correct. Agile provides rapid identification of risk. That's all.

First, let's start with risk, risk management, and risk management frameworks.

First, all risk comes from uncertainty,

Uncertainties are thing we cannot be certain about. Uncertainty is created by our incomplete knowledge - not by our ignorance

What is risk management?

Risk management is an endeavor that begins with requirements formulation and assessment, includes the planning and conducting of a technical risk reduction phase if needed, and strongly influences the structure of the development and test activities.

Two types of uncertainty create risks to an Agile Project. Aleatory (irreducible) uncertainty creates risk from the naturally occurring random behaviors of the projects. Things like defects, productivity of the development staff, estimates of effort, and random performance issues. Epistemic (reducible) uncertainties from event-based occurrences. These are probability-based. We probably needed to order more SAN for our first 3 months of operations, and we'll run out of fast-access storage. The probability that there will be 5 times the number of users logging in will crater our current server configuration. Remember the Affordable Care Act site's first months of operation. Or the probability that our test coverage is not sufficient for the needed reliability of our offering. Remember the Affordable Care Act's first months of operation? These risks are risks to the success of the project. The blog's risks are mostly process failure risks.

When we say uncertainty, we speak about the future state of an external system that is not fixed or determined

Uncertainty is related to three aspects of our program management domain:

• The external world – the activities of the program
• Our knowledge of this world – the planned and actual behaviors of the program
• Our perception of this world – the data and information we receive about these behaviors

There are several sources of risk from both Aleatory and Epistemic uncertainties.

• Lack of precision about the underlying uncertainty.
• Lack of accuracy about the possible values in the uncertainty probability distributions.
• Undiscovered Biases define the range of possible outcomes of project processes.
• Natural variability from uncontrolled processes.
• Undefined probability distributions for project processes and technology.
• Unknowability of the range of the probability distributions.
• Absence of information about the probability distributions.

The relationship between Uncertainty and Risk is:

• Uncertainty is present when probabilities cannot be quantified rigorously or validly but can described as intervals within a probability distribution function (PDF). 
• Risk is present when the uncertainty of the outcome can be quantified in terms of probabilities or a range of possible values. 

This distinction is important for modeling a program's future performance of cost, schedule, and technical outcomes. Both Aleatory and Epistemic uncertainty create risks.

These unavoidable uncertainties create risks for software projects.

The processes needed to Manage the risks created by these uncertainties include:

So, Let's look at the suggestion from the Blog that Agile Mitigates risk.

1. Sprint Durations - short cycles of produced outcomes provide faster samples to confirm those outcomes meet the customer's needs. This is a requirements validation risk reduction. However, the risk that the produced code fails to meet the customer's needs remains. You find out about it faster. While it is true that shorter sprints reduce the overall variances of the value productivity, it does not remove this variability.
2. Retrospectives - The blog mentions ineffective processes, but that's not a risk management risk. The reducible (probabilistic) and irreducible (statistical variance) risks remain. They are only reduced or eliminated with specific actions. The natural variations can be addressed with a margin. This concept is not in standard Agile. The event-based probabilistic risk can be reduced with explicit activities. 
3. Backlog Grooming - Revising and reviewing the backlog does not remove the naturally occurring variances and probabilistic events that someone must correct. Those are still there. Grooming the backlog faster keeps the probability distribution for the event-based risks and the statistical behaviors of the naturally occurring variances that create risk the same.
4. Promoting Transparency - This is an actual risk reduction process. It is not a mitigation but a process to IDENTIFY  risk.
5. Frequent Deliveries and Sprint Reviews - Again, these processes identify risks but do not mitigate those risks.

The notion that most risks can be avoided is naive at best, along with Agile preventing risks from occurring. Both are not true.

Agile provides a good means of identifying risk. Agile is NOT a risk management process. Agile does not prevent risk. Only margin or explicit risk reduction activities can mitigate risks. Risks can not be prevented. They can only be mitigated, avoided, transferred, or ignored.

Posts like this are common. It's because the source of information needed to identify, manage, and reduce risk on software projects is not being read by developers applying Agile. It's one of those repeated occurrences of using a word whose meaning is unknown.

And, of course, one final thought

In order to handle risks - reducible and irreducible - through mitigation, transferring, ignoring, or accepting the risk - we MUST be able to estimate several things about the risk:

This is Risk Management, and Agile is NOT risk management. Agile is one part of risk management - Identification, potentially tracking, a contributor to control, and a contributor to communicating the risks.