Risk Management & Agile

In one of my previous assignments as an Agile Coach the company was not working completely according to Agile methodologies. We worked in a program- and project-setting with a steering committee on top of it. Within one of the programs, we worked with a handful of teams to replace some existing applications with new stuff, and we used Agile practices like Big Room planning, Sprints, Scrum, Kanban, Customer Journeys and so on and so forth.

The more traditional focused people in the organization wanted to maintain a risk log in some form, as part of the reporting to the steering committee. The Agile minded people shook their heads, tried to come up with something to keep the traditional people from their back, and got back to work as soon as possible.

It triggered me. I got curious. What makes these worlds so far apart? Is risk management not important when you work Agile? Is it done implicitly? Or what?

To get started, what is risk management anyway?

Risk management is identifying, evaluating, and preventing or mitigating risks that might impact the desired outcomes of a project. It makes sense for each risk, to evaluate the chance the risk will occur and to think about how big the impact could be. Risk management is an ongoing activity during the project and a first version of the risk log is often an integrated part of the project-plan. This makes absolutely sense to me, because writing a project-plan at the start of a project -when you know the least- is a risky business anyway ;-).

I’m convinced that this lack of knowledge and also lack of experience, is one of the two most important reasons why risk management is important when doing projects. 

The other one is that it is still very hard to predict the future. At least for most human beings. And many projects have a long planning-horizon in which many things can happen along the way… I wouldn’t be surprised if the number of risks on the risk log, is directly proportional to the planning-horizon of your project… 

Let’s see if I can categorize the 20 most common project risks (source: https://www.stakeholdermap.com/risk/register-common-project-risks.html) as part of ‘Lack of knowledge’ or part of ‘We can’t predict the future’. 

Risk	Lack of knowledge	Predict the future
Project purpose and need is not well-defined	X
Project design and deliverable definition is incomplete	X
Project schedule is not clearly defined or understood	X
No control over staff priorities		X
Consultant or contractor delays		X
Estimating and/or scheduling errors	X
Unplanned work that must be accommodated		X
Lack of communication, causing lack of clarity and confusion
Pressure to arbitrarily reduce task durations and/or run tasks in parallel which would increase risk of errors
Scope creep	X	X
Projects conflicts not resolved in a timely manner	X	X
Business case becomes obsolete or is undermined by external or internal changes		X
Delay in earlier project phases jeopardizes ability to meet fixed date		X
Added workload or time requirements because of new direction, policy or statute	X	X
Inadequate customer testing leads to large post go live defect list	X
Legal action delays or pauses project		X
Customer refuses to approve deliverables/milestones or delays approval, putting pressure on project manager to ‘work at risk’	X
Theft of materials, intellectual property or equipment		X
Acts of God for example extreme weather, leads to loss of resources, materials, premises etc.		X
Stakeholder action delays project		X

Only two of these common risks are not directly related to lack of knowledge up-front or not being able to predict the future. This is interesting. This calls for experimenting to gain knowledge (see one of my previous blogs) and for shortening the planning horizon. Two things that are heavily embedded in working in an Agile way.

Working Agile is risk management

One of the cornerstones of working Agile is of course working in small iterations, also called time-boxes or sprints. These small iterations are usually only two or three weeks. Predicting what might happen the next two or three weeks is less error-prone than predicting a year or sometimes even longer. If something changes, we can quickly change our plan. In the worst-case scenario, we must re-do the planning of the running iteration which is only two or three weeks. We did not plan the whole project planning in detail upfront. We take it one step at the time, so the impact of a change is limited…

The other advantage of these short time-boxes is we make sure we learn fast, because we get feedback after each iteration. This feedback is both for the product that we are building (by doing a review) and the process that we are using (by doing a retrospective). Everything we’ve learned in that iteration will be used to improve the planning of the new iteration, the quality of the product or enables us to work more efficiently.

Based on the feedback we can also run experiments on either the product or the process to validate if we can improve either one of them. The experiments have a fixed time-box as well and if the experiment fails, we can quickly return to the old situation.

Final thoughts

Does this mean we don’t need additional risk management on top of this within an Agile way of working? No, not exactly. There are many examples of best practices that are in place to reduce risks in an Agile fashion. I’ll mention a few of them:

• All team members participate in things like refinement, sprint planning and estimation.
• If there is uncertainty about a technical issue a Spike can be created just to learn.
• Risk management is an implicit task of a Scrum Master.
• Quality requirements are described in a Definition of Done.

If you put a little more effort in, this list will be much longer. To me this proves my point that working Agile isrisk management. Because of the nature of working iteratively and the fact that risk management is completely integrated into the Agile frameworks and best practices. 

A separate Risk log is no longer needed. Risks might surface as items on the Product Backlog (spikes) or tasks within a PBI, or maybe on the Scrum Masters to-do-list or impediments board.

I’m curious… what do you think? Case closed? Or not? Would love to hear!