When I started developing software back in the 80s the world we lived in was a little different. Our understanding of best practices was mostly based on tried and trusted principles derived from other types of engineering and handling risk was a core part of project management. Today in our new enlightened Agile world, you hardly hear the word mentioned. Is that right, is worrying about risk a thing of the past?
Well, some people would say yes, it is. That all sounds a little difficult to swallow when you remember that only a few years ago it was a high priority agenda item and now we are saying it’s not worth bothering about? Could this be true? So I started to look at risk in an Agile world and did a little research and R&D. I think it was certainly worth the effort. For now, let’s look at the opening question of do we need risk management at all?
The argument often made is the biggest risks in developing software are either delivering the wrong thing or not delivering anything at all and Agile mitigates these risks. Short feedback loops ensure we are on track to solving the right business problem. Focusing on building working software with minimum features early helps us limit the risk of not delivering. So, simply working in an Agile way addresses the big risks and the rest of them, well, it’s simply more effort to deal with them than the impact they can have. Sorted!
So, all our problems have vanished because of the way we work. Wouldn’t that be nice! Well it would be, but I don’t think that’s the case.
While these ways of working I think do address these big risks to a significant degree, what’s left could still blow your project out of the water just as easily as they did in the 80s. There are quite a few types of risk that simply are not covered by using an Agile way of working. What about key man dependency, third party suppliers, compliance, market/competitor movements and reputational risk, to name a few. We can also can create additional risks by working in an Agile way. What about the architecture? If we rely on emergent design without nurturing it as many do, do we not face a risk of a poor design? I am sorry to say I have seen many weak designs come out of Agile projects.
Eric Ries and Alistair Cockburn make the argument that Disciplined Learning and a focus on seeking understanding from the onset as a key deliverable of effort will mitigate a lot of the problems we face. I can see some great value in this for sure and spending effort to understand your domain better will again reduce some types of risk. Alistair talks about learning about the product, the team, the architecture and the costs. By taking a broader view I think this can help us mitigate some risks even further. But even with a great learning environment in place do we have all the bases covered?
I think the world of risk is different in an Agile environment. We have some great ways of reducing some of the big ones, I will agree with that, but I think some risks fall outside the ability for Agile techniques to address. And, just because Agile can help us mitigate these classes of risk, does that mean we can simply work in a world where we are completely unaware of risks and hope whatever is ‘out there’ is all covered? That sounds a little scary in itself. Think about the Agile projects you have worked on in the past. Did some of them feel inherently more risky that others? Were you happy to ignore these thoughts and just carry on as usual or did they make you act differently?
How we can do this better? Well, that’s a discussion for another time. For now, I would be happy if you can see that Agile projects still probably have risks that needs attention. We may have come a long way from the 80s but we are still trying to achieve the same thing as we were before and developing software is still a risky business.
If your organisation is seeking support in managing risk effectively on its Agile projects and programmes, please get in touch.