We all know that software development is risky. We’re creating something new, with an uncertain set of requirements, in an often-tight timeframe. On top of that, we have to worry about unknown dependencies, sudden market changes, and personnel shifts!
It’s no wonder then that many believe that without some sort of risk management strategy, their bright and shiny new project will tarnish quickly, along with their reputation. And this is where the confusion sets in. Agile frameworks like Scrum and Kanban don’t explicitly mention risk at all—so should agile organizations implement a formal risk management process on top of their agile framework? Before you answer yes, consider this.
Agile IS Risk Management
When I was writing my Essential Scrum book, I kept asking myself, “Do I need a separate chapter for Risk Management?” In fact the original outline I gave my publisher identified a Risk Summary chapter.
In the end, I decided that the concept of dealing with risk is so fundamental to agile that the discussion of risk, randomness, volatility, variability, and uncertainty was already woven into the other chapters. It also became clear to me that a separate chapter on risk management, even just a summary chapter, might actually send the wrong message—the message that agile development requires a formally defined, document-driven, heavyweight risk management process as is typically defined in traditional project management circles. It doesn’t.
In fact, I believe the existence of a heavyweight risk management process is a good indicator that a company has failed to embrace the essence of what agile is.
I’m not suggesting that in some domains (e.g., developing pace makers or other life saving devices) we shouldn’t put more of a focus on risk identification and mitigation than in other domains (e.g., creating simple websites). We should. However, keep in mind that many of the risks on mission-critical systems can be addressed using the risk management that is inherent in the proper application of agile principles.
I recently delivered a presentation entitled Agile IS Risk Management that explores this topic in detail (as well as the material in the rest of this blog). You can download that presentation here.
Three Approaches to Agile Risk Management
I have identified three approaches that give organizations a solid basis for dealing with the uncertainty inherent in product development, no matter their domain.
- When appropriate, use minimal traditional risk management techniques in the simplest possible way. When failure threatens lives, and when there is a good reason to believe it would be helpful, organizations may employ more traditional risk management techniques than in other situations.
- Adhere to core agile principles to avoid the self-creation of inherently risky or uncertain situations. In other words, by working in an agile-like way, we can simply avoid certain situations. For example, if you want to avoid the risks of fixed-price contracts, then don’t enter into fixed-price contracts!
- Apply agile principles to make the development process robust and at times antifragile to the disorder of uncertain events. In other words, use agile to avoid the harm and reap the benefits of uncertainty without the need for a heavyweight risk management process. Yes, I just said that risk (I prefer to call it uncertainty) has an upside that we can and should embrace. (I also borrowed the concepts of robust and antifragile from the book, Antifragile: Things that Gain from Disorder, by Nassim Taleb. I will formally define and apply these terms in a future blog post.)
Since a good discussion of all three approaches would be unreasonably long for a single blog posting, I will create a series of blog postings to address the topic of uncertainty and to detail these three approaches. The next blog in this series will define a mental model for uncertainty that will provide a foundation for discussing the other topics.