In this article, we’re addressing a common question in modern project management: Do we need risk management in agile projects? Yes!

Let’s expand that simple answer.

Do agile projects have risks associated with them? Yes, of course, they do. And do we want to let those risks run wild without any effort to contain them? Of course not. So, yes, of course, we need risk management in agile projects.

But I’m sensing you’ll still want more from me.

So, let’s start again.

Why is Risk Management in Agile Projects Even a Question?

Agile project management is a stripped-down version of ‘traditional’ project management that takes different approaches to planning and managing change. We learn as we go and take small steps with defined budgets, resourcing, and time-boxes. As a result, some people might expect that agile projects have – or even need – no risk management. That is completely wrong.

But there is a reason why such expectations may be reasonable – at least in part. As we will see, agile methods are, to a degree, a response to the kind of risks that software development projects face. So, we might say that agile project management has a lot of risk management baked into the framework.

So, it’s easy to think that Risk Management would be completely different in agile projects – that would be wrong too. However, it would be equally wrong to think it will be just the same.

Traditional Project Managers Can Learn a Lot from Agile Risk Management

The truth is that risk management is an absolutely necessary part of agile project management. It is both similar to and different from the way we do it in predictive project management. While the principles remain the same, agile methods give us additional risk management ideas.

So, there is a lot that traditional project managers can learn and adapt from the way risk management works in agile projects.

Your Overall Approach to Risk Management

We need to adapt our standard project risk management approach to the nature of every project we do. We need to consider things like:

The level of risk
This involves things like the complexity and the novelty of what we are trying to achieve, its scale and therefore cost, and the political, social, or economic consequences that are at stake.
The attitude to risk
The risk attitude of your customer, client, users, or sponsor will dictate not only what risks you are willing to accept (risk tolerance), but also the intensity of your risk management processes.
The culture of the sponsoring organization
This also impacts risk tolerance and risk appetite. However, its biggest practical impact will be the risk management processes and infrastructure the organization imposes on its projects. Often, this is through its Project, Program, or Portfolio Management Office (PMO).
The style of project management
The organization may have a preferred methodology or paradigm, and the project manager (along with their team) will also assess what is right for this project. You will seldom conduct a ‘pure agile’ or ‘pure predictive’ project. After all, all project management is hybrid project management!

As you’d expect, risk management is more adaptive and emergent in agile projects, compared to traditional, plan-driven projects. Because agile projects tend to time-box activities, the risk incurred at any one time is often less. So the differences will be real – but not as stark as ‘no risk management in agile projects’!

"You will seldom conduct a 'pure agile' or 'pure predictive' project. After all, all project management is hybrid project management!"

The Two Levels of Risk Management Process Application

Whilst the basic risk management process is the same, the first big difference is that, in agile projects, we typically apply that process at 2 levels:

Level 1: The Project level

An over-arching Risk Management framework identifies whole-project risks and sets up both systemic processes and specific actions to manage them

Level 2: The Iteration, or Sprint, level

We apply risk management throughout each iteration, starting with setting the goal for the iteration (the Sprint Goal in Scrum), through to closing out the risks (or carrying them over) at the end of the iteration.

Project Level Risk Management in Agile Projects

We can describe the core project risk management process in many ways. But the essence of it, using my preferred terminology, is:

Identify your risks
Analyze (and prioritize) those risks
Plan your risk responses
Take action to manage the risks
Monitor & Control the risk management process

In agile projects, we would do steps 1 to 3 early on, before the first iterations, and we would carry out steps 4 and 5 during each iteration, revisiting 1 to 3 between iterations.

If you run your agile project from a Kanban board, you will apply these five steps to the whole board.

But an important thing to note is that, even in the most traditional of traditional, predictive projects risk management is and has always been an iterative process. What agile adds to this, therefore, is a distinct cadence of its own iterations or drawdowns of tasks into the Work in Progress part of the Kanban Board.

Iteration (or Sprint) Level Risk Management in Agile Projects

We also follow the whole risk lifecycle during each sprint or iteration. In drawing down items from your product backlog, you need to be thinking about:

The risks related to each item or story.
The overall risk that the items create together, to the iteration or sprint.
The consequent risks they create for the project as a whole.

The team needs to identify, analyze, and plan for the risks as part of its Sprint planning. I would argue that this increases, rather than diminishes, the focus on risk in an agile project. This can be further enhanced by discussing risks at daily stand-up meetings.

In a Kanban project, for each task, we will go through the same process before moving it to become work in progress. We will therefore need to manage the risks associated with the task, as part of doing the work on the task. So, in many ways, agile project management builds risk management into task delivery.

How Agile Project Management Builds In Risk Management

In addition to the things we have already discussed, there are other ways that agile methods build in risk management. But first, let’s recap:

Agile project management methods build in risk management in the following ways:

Risk-thinking on selection of tasks, items, or stories for drawdown.
Management of risks as part of task, item, or story delivery.
Discussion of risks at morning stand-ups.

However, I think there are three aspects of agile frameworks and methodology that particularly emphasize and strengthen risk management.

1. Adaptability of Agile Projects

The adaptability of agile thinking is a response to a specific risk inherent in software development – the original domain in which agile arose. This is the uncertainty of the end product. Customers and users are often unable to properly predict what the whole end product will need to look like. There are many reasons for this uncertainty about what they will need, such as:

The need to understand what the end-user will actually want or need.
The inability of that end-user to anticipate what is possible and how they will use it.
Rapid changes in the market demand arising from social trends, competitor activities, or technical capability, for example.
Rapid development in the technology available.

So, agile project management responds with an incremental approach. Each iteration bites off a small chunk of work and thus limits risk. At the end, the team can then survey what they have learned and what has changed externally, before deciding what the next chunk should be.

And, as the pace of change rises and risks increase, we typically reduce iteration cycle time.

2. Use of Backlogs and Spike Stories in Agile Projects

The use of a backlog is also a risk management approach beyond the staged drawdown:

We can deliberately defer high-risk tasks (especially those with a high uncertainty) until we have more knowledge and greater process experience. In this way, when we come to tackle these items, we can do so with some elements of the risk already lower.

We can take this further with the use of ‘Spike Stories’ to answer a specific question that can reduce uncertainty and therefore risk. A Spike story is also known as a ‘timeboxed investigation’. They are stories (or tasks) that the team creates for the sole purpose of exploring an issue to increase their understanding, reduce uncertainty, and improve estimation and decision-making.

3. The Power of Reviews and Retrospectives

Agile practitioners have an exemplary attitude to reviewing their work and learning from their experiences. Whether this arises from the rituals the community has created or whether they created those rituals as a response to that mindset is not a question that I feel able to address.

However, to illustrate with Scrum, let’s consider the Sprint Reviews and Sprint Retrospectives of Scrum.

Sprint Reviews

Sprint reviews are where the development team showcases the work they have done in an iteration to the customers, users, or stakeholders. From the discussion, the review group can consider:

the impact of this work on the whole-project risk, and on backlog items and their estimates
the risks arising from the work done, especially if further work is needed

Sprint Retrospectives

Sprint retrospectives are where the development or project team reviews their way of working. So, a retrospective can sharpen the team’s risk management practices and therefore reduce risk through the project life cycle.

Sprint reviews and retrospectives can both lead to the team making updates and additions to the project risk register.

The Big Challenge for Risk Management in Agile Projects

I see one principal issue with risk management in agile projects, and it may be why many people wonder if there is any risk management going on!

Typical agile frameworks do not include a clearly defined risk owner or risk manager. The entire team is responsible. This can, of course, be a benefit. In a well-run project – with a capable Scrum Master, for example, the team will discuss, own, and allocate risk management tasks effectively. But this can also lead to individuals taking a laissez-faire ‘leave it to someone else’ attitude.

This lack of ownership and the wider risk management benefits of the agile approach can lead to a cavalier attitude towards risk: ‘there’s no need to worry’. This is, itself, a risk.

"This lack of ownership and wider risk management benefits of the agile approach can lead to a cavalier attitude towards risk: 'there's no need to worry'. This is, itself a risk."

What Traditional Project Managers Can Learn from Risk Management in Agile Projects

I hope you have been persuaded that not only do we need risk management in agile projects, but that there is a lot that traditional Project Managers can learn from the best agile practices.

In particular, I’d select to focus on:

Agile Mindsets of:
- Transparency – making for better risk identification
- Collaboration – delivering better planning and problem-solving
- Customer involvement – offering greater accountability, business participation, and expectation management
Agile Principles of:
- Incrementalism – allowing rapid change with little loss or rework
- Learning a step at a time – leading to better time and cost estimating
- Time-boxing – reducing risks of over-run and over-spend
Agile Processes of:
- Backlogs and drawdown
- Spike Stories
Reviews and Retrospectives

Do We Need Risk Management in Agile Projects?

Why is Risk Management in Agile Projects Even a Question?

Traditional Project Managers Can Learn a Lot from Agile Risk Management

Your Overall Approach to Risk Management