The Agile Manifesto was published in 2001, but agile is still a hot topic in project management. In theory, agile project management is supposed to reduce risks by design, so that ultimately there are no risks any more.
As a result, alongside backlogs, user stories and velocity in the agile approach, there seems to be no place for risks. For example, there is no risk backlog.
So where are all the risks in agile projects? Have they really disappeared? Three claims of the agile approach imply that this might be true:
1. Using an agile approach massively reduces risk.
Right and wrong. It is true that the agile approach reduces some risks, such as the possibility of developing products that the market does not need.
Used correctly and constantly, communication and iteration make it nearly impossible to miss the market. But the risk of developing the wrong product is only one type of risk.
Risk is defined as the effect of uncertainty on goals. Since all agile projects, releases and sprints have goals, there will also be risks.
2. Risks are managed through the impediment backlog.
Wrong. The impediment backlog provides a list of current obstacles. Impediments are like issues: they are problems that need to be resolved now.
Some impediment backlogs probably also contain real risks, but that isn’t their main purpose. So, if it is used properly, an impediment backlog cannot help us to manage risk.
3. Risk is avoided through close cooperation in the team.
Wrong. Of course, good cooperation within a team, working in one place and without constant interruptions is beneficial for successful project work. It will avoid some risks, but not all.
Effective risk management is usually correlated with project success. But if projects conducted in an agile environment need no active management of risks, then do they all succeed?
If we focus only on the risk of missing the market needs, then perhaps it is true that agile projects are more successful than traditional projects. But within agile projects it is a different story.
Much of the work turns out to be redundant. Product owners neglect their duties. The agile method is misinterpreted and misused. Managers expect miracles.And the tendency to believe that agile projects don’t need documentation only makes things worse.
It is definitely not true that adopting an agile approach means the end of all risks.
How might a risk backlog help? Within a sprint, the team will be able to proactively identify avoidable problems and capture unexpected benefits.
The product owner should not only keep an eye on risks in the sprint risk backlog, but they should also monitor opportunities and threats linked to this goal level. And senior management will be alerted to ways in which the corporate culture needs to change to support the agile approach, especially if the organization is mainly hierarchical.
Of course, we can adopt some of the new agile techniques when identifying, assessing and managing risk.
For example, we could invent a creative way to measure impact in risk points. We might play a few rounds of risk poker with our team to estimate probabilities. We can produce attractive and colorful risk burndown charts.
This is all good. But in the end, the most important thing is to use risk management to help you achieve your goals — even in agile projects.
