A favorite blog is Critical Uncertainties where Matthew Squair writes about risk. Risk in broad terms. But risk in a narrow term is just as important and just as critical.
Thanks to Matthew for the picture to the left and the quote of Lord Thompson, before he boarded the airship headed to India. The R-101 is as safe as a house, except for the millionth chance.
In the software development business, risk results from uncertainty. Risk that we'll overrun our budget. Risk that we'll show up late. Risk that what we produce won't actually work. Risk that what we produce won't be what the customer thought they were getting.
Agile development is many times billed as a risk management process. Which is both correct and incorrect at the same time. A principle of Agile Software Development - and Agile is a software development method - focuses on mandatory production of outcomes in short periods of time. These outcomes - working software - can be assessed to be compliant with the customer needs. These short periods of time provide inch pebbles on the path to completion of the collection of needed capabilities. These frequent outcomes provide feedback needed to take corrective action when those outcomes aren't what the customer wanted. But this feedback is a lagging indicator. It's after the fact. Do the work, look at the results, adjust. The probabilistic future risk and it's probabilistic choices to take corrective action to reduce risk or margin to protect from a risk, are not a core competency of Agile. More is needed on top of the feedback process to protect future evens or variances from impacting the emergent outcomes from the agile development process.
Agile is not a risk management processes per se. Agile doesn't address the core practices of Risk Management, shown to the left.
Agile does not identify risks upfront, analyze those identified risk, plan for their reduction in explicit ways, track them in risk burn down ways, control them in advance. Agile can respond to a risk when it is encountered. By that time the risk has turned into an Issue. Changes to the project can then be made to go a new direction, but only when the working software is present can that decision be made.
Risks are probabilistic. These probabilistic risks come from one of two sources. There is a probability that an event will occur in the future that will unfavorably impact the outcomes of the project. These type of uncertainties come from the lack of knowledge. They are epistemic uncertainties. This missing knowledge can be bought. Agile can buy this knowledge by producing something that can be assessed. Money can be spent to develop an incremental outcome that can test an idea, an outcome, a capability to determine if it is what the customer wants. But doing this work requires time and money. So planning for this time and money has to be part of the development process.
There are statistical variances in the project that will impact outcomes as well. We can't buy down these processes. They are Aleatory. They are Irreducible. The only solution for aleatory uncertainties - irreducible uncertainties - is margin. Cost margin. Schedule margin. Technical margin.
To determine these margins we need several things:
- A model of the underlying statistical processes that produce the irreducible uncertainties - the naturally occurring variances. These models can come from past performance - we've done this many times and the most likely value is X, with the least value being X-15% and the highest value being X+25%.
- A parametric model where the observed past values are scaled to match the current model.
In either case - and other modeling approaches - this type of risk analysis produces probabilistic ranges of values that might occur. Rather than a probability of occurrence - which is an event.
Since both reducible and irreducible risks result from the underlying uncertainties requires us to estimate both the probabilities for event based outcomes and estimates for the range of possibilities from aleatory risks.
So when we revisit the title of the this post Risk Management is How Adults Manage Projects - Tim Lister, we see that Estimating are required to manage risk, since risk is always in the future, driven by underlying statistical process, emergent (event based and reducible) or natural variable process (probability distributions, and irreducible).
