There have been several posts of late about agile development, failures, and risk. Let's start with Tim Lister's quote.
Risk Management is How Adults Manage Projects
But managing risk has many varieties and approaches. From informal lists of what can go wrong to formal risk management processes with probabilistic tools. No matter the approach, there is a common starting point. This point is to recognize there are two classes of uncertainty that drive risk. Yes, it is uncertainty that is the source of risk. Risk comes from uncertainty.
Aleatory uncertainty creates a risk when we fail to account for the nature variances in the project. Effort duration variance occur naturally. When we don't have schedule margin, we will be late if everything doesn't go perfectly.
One flaw of the agile development paradigm is there is usually no margin in the iteration. The iteration and other higher cycles are time boxed. 4 weeks. If the planned features or stories didn't get done, we'll just move them to the next cycle. This is fine, except we're mortgaging the future. Building story debt. That is fine if there is no planned deadline for a set of features or capabilities. We'll be done, when we're done.
For Epistemic uncertainty creates risk when we fail to understand the probability of occurance for an unfavorable event. What's the probability it will rain on our company picnic two weeks from this Thursday? Let's look at the forecast. The weather forecast is a probabilistic statement about rain over the forecast area. If we know the local micro-climate, we can interpret this to mean something about the specific locale. For Niwot Colorado, in our neighborhood, a 30% chance of rain for Boulder County, means a zero chance of rain. We're in the shadow of Niwot Ridge, and are essentially a desert, with cactus growing in the untended portions of our backyard. The probability of rain needs to be above 60% for us to have any chance of rain.
Epistemic uncertainty has a probability of occurance. With this occurance, there is an outcome. The unfavorable outcome is a risk for the project. There is a 70% probability that the integration and test of the Ku Band receiver will cause an over temperature condition in the avionics bay of the helicopter. This is an Epistemic uncertainty.
We need a mitigation if this were to occur. These mitigations can retire the risk - run the thermal modeling software to determine with the current design and safety margin how much cooling we need. Or a risk response with it occurs - we have fire extinguishers on hand.
Both of these classes of uncertainty create risk. Both need handling&plans. For aleatory uncertainty, margin is needed, since we can't fix the risk, or make it go away. It's just there. On projects, this is cost and schedule margin, a Plan B, or the ability to slip the schedule.
For Epistemic uncertainty, the best way to handle it is with a risk retirement plan. Pay to make the risk go away, or be reduced to a low enough probability that we have margin to cover the consequences. Make an Epistemic uncertainty into an Aleatory uncertainty.
For Agile Development
I've said this in the past, but it's worth repeating.
If there is no risk management strategy, then the Agile teams are just observers of the unfolding events of the project.
There must be some form of risk management. Agile alone is not risk management. It's only mitigation strategy is to move the unfulfilled features to the next iteration. In many domains, that's called I'm late, over budget and my stuff doesn't work yet.
So for anyone applying agile software development, remember to ask those pesky questions - what can go wrong? Do we have any margin in our iterations to handle the aleatory uncertainties of productivity? What things do we not know enough about now, that we can do some work on to gain new knowledege tp avoid or retire an Epistemic uncertainty?
Not asking those questions? It's going to be a long hard road.
