This blog is the sixth in a series about agile and risk management. The first five blogs are:
- “Three Key Agile Risk Management Activities”
- “Agile & Risk Management: The Mental Model of Uncertainty”
- “Agile & Risk Management: Antifragile”
- “Agile & Risk Management: The Role of Traditional Risk Management”
- “Agile & Risk Management: Managing Risk Via the Product Backlog”
In this blog I discuss how applying agile properly can help us avoid certain risky situations altogether.
If You Don’t Want To Run Out Of Fuel in Space, Don’t Go into Space!
One way to keep risk at bay is just to stay out of risky situations. Why put yourself in harm’s way if you don’t need to?
In the 2014 blockbuster movie Gravity, Sandra Bullock’s character finds herself in a spacecraft that has exhausted its thruster fuel. She is looking at the very serious prospect of dying in space.
Well, she certainly has gotten herself into quite a pickle! If she’d stayed on Earth, she wouldn’t have had to worry about the risk that her spaceship could run out of fuel!
So is that what I mean by avoiding risky situations—just play it safe and all will be well? No. That isn’t what I mean. I am among the many who believe that there is substantial upside to exploring space, so perhaps the risks of adverse events in space are worth the rewards.
When I suggest that we stay out of risky situations, I’m not trying to suggest we become risk-adverse to the point were we fail to extend our horizons. Instead, let me generalize my point beyond the Gravity example: If we avoid taking certain unnecessary actions, we can avoid certain unnecessary risks.
Just Because You’ve Always Done It, Doesn’t Mean You Should
Let’s use an example a bit closer to home (both literally and figuratively): Fixed-price contracts. If you don’t want to deal with the risks of fixed-price contracts, then don’t enter into them. It’s really that simple.
Okay, maybe not that simple—perhaps your legal department requires them, and changing its mind might be difficult! But, think about all of the risks that come from a contract where date, scope, and budget are all locked down at a point in time when you have poor project knowledge (the very beginning). Core agile principles make it clear that locking down all of those variables is very risky.
Now imagine a situation where your contract was more agile-like: a situation that was not over constrained and also didn’t make the parties to the contract adversaries from the onset. In such a situation, we could avoid the core risks (e.g., wasteful change control, inevitable cost overruns, etc.) inherent in a fixed-price contract.
Opportunities to avoid unnecessary risk are everywhere. Worried about the bugs you might find in the integration phase? Skip it. Adopt continuous integration and deal with small, manageable problems as you go.
Concerned that your huge, upfront requirements document doesn’t capture everything, or doesn’t describe the right thing? Don’t write it. Use a product backlog created through progressive refinement and small delivery cycles to build valuable content a little at a time, then inspect and adapt.
In other words, choose a more agile path. Take only the risks that are essential for success while avoiding needless risks whenever possible.
The Economics of Not-So-Risky Business
To better understand the economic significance of avoiding unnecessary risks, let’s leverage the mental model of uncertainty that I have used in this Agile and Risk Management blog series.
Look at the effort you would save if you keep just one uncertain event out of this model! For each uncertain event that you don’t create, you get to avoid the full expense of applying this model to deal with it.
One of principles in the agile manifesto that is quite appropriate in our discussion is: “the art of maximizing the amount of work not done.” In our case, the most economically sensible way of dealing with risk is to avoid injecting risks into the system in the first place. Look, we have plenty of uncertainty that we can’t avoid; I see no reason to pile on more risk when we don’t have to!
Conclusion
What do you think? What are some of the costly, project-crushing situations you could avoid just by applying core agile principles during development? Leave a comment so we can continue the conversation.