Traditional Risk Management on Agile Projects

In the Agile classes that I teach, there are often participants who undergo mental, emotional and (sometimes) physical discomfort at the thought of letting go of the old way of doing things. The symptoms are obvious. Some fight back with questions that seek permission to skip a rule or two. Some keep trying to redefine Agile in a way that turns it back into waterfall and some just sit there, making the kind of faces people make when they are having digestive issues.

Don’t throw it all away

Here is the thing…you don’t have to throw all of it away. There are some bits that are definitely worth keeping. The trick is knowing which ones are which.

In my practice of Agile, which is mostly centered around Scrum, one of the traditional practices I find continues to have value is traditional Risk Management.

When I am working with teams I typically schedule a Risk Management meeting that will be held at the same time, in the same place, on the same day, every week. When the project is starting up, I make a big deal about it and push hard to get management involved. I specifically present it as a traditional project management tool that I want to include in our practice of Agile. And then I beg, I plead, I bribe them with food… whatever it takes to get them in the room.

Initial Meeting

During the initial meeting I spend time explaining the differences between risks (things that might happen) and issues (things that have happened). I explain that in this weekly meeting we will discover risks, explore their potential impact, prioritize them and plan a response. I show them a risk register, present an example to demonstrate how it works and how we will use it to track and monitor risk throughout the life of the project. I explain that the risk meeting will be held each week for the duration of the project and that their participation is vital to the success of the project and that I will be present for the meeting each week whether anyone else attends or not.

Then we hand out post-its and everyone begins identifying the things they are worried about. The only rule is that we are focused on finding, not solving. We collect them all, sort them, remove duplicates, establish themes we want to use to categorize them and begin our intial prioritization. This is the beginning of our Risk Register, which is basically just a big backlog of risks.

Then, one by one, we talk through the risks, entering data into the fields as we move across the row. Often times, talking about a risk will generate a bunch of new risks… which is a good thing. As we work through probability and impact analysis of each risk, we often find that priority will shift. Also a good thing.

If you’d like to check it out, here is a Risk Register Sample. It includes an explanation of each field.

Risk Register

Having the Risk Register is a great way to capture and monitor things that might creep up and bite us as we work through the project. It’s a good thing to have. But that is not the only reason I include this traditional project management practice on my Agile projects. Most of the projects I get to work on are in organizations that include a mix of traditional and Agile. Often times, these organizations are in the early stages of Agile transition. So, in addition to the normal stress of a project, we now have the added complexity that comes from introducing a new way or working as well as management, who may not entirely understand all the ways that Agile will impact them and the data they receive about projects.

In short.. lots of stress. Stress is way bad. Stress results in poor decision making, panic and worst of all leadership who feel they need to step in and (gulp) “help” the people doing the work.

Actually documenting, evaluating and planning for all the things that might go wrong is a great way to plan for the rainy days we are going to encounter. If any of those risks evolve into issues, we’ve got a plan. Many of them won’t, and that is okay. The time spent talking about them is not waste if the discussion frees up our minds so that we can be more focused on the things we didn’t think of that crop up along the way.

What I have found though, is that one of the reasons this meeting is so important is that it gives the people who worry about the project a place to come put those worries down. Once they realize that by bringing it up in this meeting, it will be thoroughly considered, planned for and monitored, the stress, by and large, disappears. Having a place where people can unburden themselves of the things that worry them can go a long way towards freeing them up to stay focused on the work that leads to shippable product.