The post Top 5 Ways Agile Mitigates Risk is one of those posts that's not wrong in what it says at the detail level - more or less, but is 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.
There are two types of uncertainty that create risks to an Agile Project. Aleatory (irreducible) uncertainty creates risk from the naturally occurring random behaviours of the projects. Things like defects, productivity of the development staff, estimates of effort, random performance issues. Epistemic (reducible) uncertainties from event based occurrences. These are probability based. The probability that we didn't order enough 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 is users logging and and this 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 sit'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 speak of uncertainty is means
- When we say uncertainty, we speak about a 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 used in defining 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 in a rigorous or valid manner, 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 the future performance of cost, schedule, and technical outcomes of a program. Both Aleatory and Epistemic uncertainty create risks.
And these unavoidable uncertainties create risks for software projects
The processes needed to Manage the risks created by these uncertainties include
So Let's at the suggestion from the Blog that Agile Mitigates risk
- Sprint Durations - short cycles of produced outcomes provide faster samples to confirm those outcomes meet the needs of the customer. This is a requirements validation risk reduction. But the risk that the produced code doesn't meet the needs of the customer is still there. You just find out about it faster. While it is true shorter sprints reduce the overall variances of the productivity of value, it does not remove this variability.
- Retrospectives - the blog mentions ineffective processes but that's not a risk in the Risk Management sense. The reducible (probabilistic) and irreducible (statistical varaince) risk are still there. They are not reduced or eliminated without specific actions.
- The natural variations can be addressed with margin. This concept is not in standard Agile.
- The event based probabilistic risk can be reduced with explicit activities
- Backlog Grooming - revising and reviewing the backlog does not remove the naturally occurring variances and probabilistic events that someone will go wrong. Those are still there. Grooming the backlog faster doesn't change the probability distribution for the event based risks or the statistical behaviours of the naturally occurring variances that creater risk.
- Promoting Transparency - this is an actual risk reduction process. No a mitigation, but a process to IDENTIFY risk.
- Frequent Deliveries and Sprint Reviews - again these are process that IDENTIFY risks, but do not mitigate those risks.
The notion that most risk can be avoided is naive at best. Along with Agile preventing risks from occuring. 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 explicitly risk reduction activities can mitigate risks. Risk can not be prevented, they can only be mitigated, avoided, transferred, or ignored.
Posts like this are common. I'd suggest it's because the actual source of information needed to identify, management, and reduce risk on software projects is not being read by developers who are applying agile. It's one of those repeated occurrences of using a word that the meaning is not known
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:
- The probability of occurrence of the reducible risk
- The range of naturally occurring variancs for the irreducible risks
- The probability that he mitigation will be effective
- The probability of any residual risk post-mitigation
This is Risk Management, 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.
