Agile and risk management
The Misconception that Agile doesn’t recognise risks
There is a strange misconception going around that people working in Agile software development don’t consider risks, or don’t manage risk, or don’t take risk seriously. This is in fact quite false. This article will attempt to clear up the relationship between agile and risk management.
The Waterfall approach to risk – log everything!
Traditional Waterfall projects being run according to traditional Project Management methodologies (PMBOK, Prince2, etc.) talk about risks a lot. And the general approach can be summarised as: log everything!
These project managers are great at logging risks. They like to spend days and weeks talking about risks, writing down risks, rating and ranking risks, doing risk analysis and risk identification, coming up with risk mitigation strategies, logging risks into risk management systems, discussing risks, reporting risks, escalating risks, re-prioritising risks, and general messing about with risks.
A lot of them probably feel that Agile methodology projects (e.g. Scrum or Kanban) are crazy cowboys because they spend very little time doing those things, so probably have no clear understanding of what risks they face. I would disagree with this position. The difference is in the approach: manage risk versus de-risk.
What’s wrong with the Waterfall approach
There are two main problems with this Waterfall approach (and their risk analysis / risk management framework). The first is that it assumes the job of the project manager is simply to monitor and report risks, rather than do anything about them. The second is that it tends to ignore the biggest risk of all: that the thing produced will not be valuable to customers.
What if instead of just observing, there was a way the project manager could structure the work so that it avoided most of the important risks on the project? Including this large and largely ignored risk?
It turns out there is: agile software development. Which achieves this through the early and frequent delivery of value.
Agile and risk management – derisk the project from the beginning
Agile approaches to software projects spend a lot less time creating logs and artefacts around risks than Waterfall projects. People doing agile project management spend a lot less time in meetings about risks than Waterfall projects.
Instead of logging and talking about risks, i.e. “managing risk”, Agile approaches attempt to de-risk the project from the beginning, through a variety of practices, but mainly:
- early and frequent integration of code, aka Continuous Integration
- also early and frequent testing of software, aka Automated Testing
- and early and frequent delivery of software to customers, aka Continuous Delivery.
Those DevOps themes are in increasing order of difficulty and importance.
Continuous Integration is easy; there are some good books on it, but most developers understand and can do it. Automated Testing is a bit harder and involves pipelines, automated testing frameworks, stubbing, and so on. Continuous Delivery (i.e. extending your pipeline all the way to production) is harder and involves the previous two, done really well, plus more parts.
Agile reduces risk from the beginning
The approach for agile and risk management is quite simple: remove risks.
- early and frequent integration of code mitigates the risk of late integration of code causing merge issues (aka “integration hell”)
- also, early and frequent testing of software mitigates the risk of late discovery of defects (aka “System Integration Testing Hell”)
- and early and frequent delivery of software to customers mitigates the biggest risk of all: that nobody wants what you have built (aka “we delivered this project but it was a flop”).
The idea is to increase information and reduce risk from the beginning. The waterfall approach means you don’t get much information until very late. At which point change is difficult and expensive and carries more risk.
The waterfall approach looks something like this:
As you can see, information tends to arrive very late in the project cycle. This is due to late integration of code, late cycles of system testing, and late and once-off delivery of functionality. This means risk is piled up until late in the project, where it may be difficult or impossible to do anything about issues that come up.
While the agile approach looks more like this:
Early and frequent integration, testing and delivery means that information comes in early and frequently. This reduces the risk profile of the project significantly.
Sprint Planning helps too
Teams doing Scrum will be doing planning frequently in small chunks, i.e. sprint planning. Which usually happens every two weeks on agile projects. The team keep going back to the product backlog, inspecting and refining it, and choosing backlog items (such as user stories) for the upcoming sprint.
This shorter planning horizon means that risks are identified and assessed and re-assessed more frequently. Which provides a further advantage for risk assessment in agile.
I hope that clears things up! Have you had any particular experiences or insights around agile risk management / agile risk mitigation / agile risk response? If so, let me know in the comments!
And if you’re still not sure about how agile works with risk management, this video might help you understand it.
