Agile Risk Management

June 17, 2008 by JurgenAppelo

Today's evaluation of one of our projects was a tough one. It seemed like nothing had gone right. The customer had signed the contract far too late, which meant that resource management had to switch to another (inexperienced) team, because the original team was already booked for other projects; the platform to be used turned out to be much older than anticipated; the customer singlehandedly decided on a live release date, and forgot to inform anybody else on the team about it; half of the requirements turned out never to have reached the proper team members, due to some stupidly bad communication; and beta testing was a nightmare because the customer hired a third-party service organization, and the development team was not allowed access to the beta testing environment.
Needless to say, the first release of the project was bad. Really bad.
Could we have prevented our problems?
Of course!
Do the agile methods have anything to say about such problems?
(In our case) nothing useful!
Can we solve these problems by adding more processes?
Absolutely not!

Sometimes, unexpectedly, you have to work with a bad environment as it is handed to you. You can jump high and low, you can cry, you can shout, and you can kick the customer in the groin (I often do all of that, just to let off some steam), but it's not going to change anything. You will simply have to work with what you got.
Processes (including best practices promoted by agile methods) can only deal with known environments. (In fact, agile methods usually define their boundary conditions, like "customer on site" and "colocated team members".) But if you don't know the environment for a process, then you cannot define the process! That's why software development methods always tell you to A) change the environment to better fit the process; or B) change the process to better fit the environment. However, every problem we faced in our little-project-from-hell had its origin in unforeseen circumstances.
Standard processes, by definition, cannot deal with unforeseen circumstances.
Only intelligent people can.
That's where the concept of Risk Management comes in. Risk Management is part of Prince2, part of PMBOK, and part of the CMMI, but you don't often see it addressed explicitly in books on agile methods. I think that's strange, because Risk Management is nothing more than a simple approach of managing potential problems that are not addressed by the standard processes, and that usually find their roots in unforeseen circumstances. Risk Management is a 100% human activity concerning problem-solving. It is self-organization on the supra-project level.
So, how do we implement Agile Risk Management?
Easy! Make somebody directly responsible for keeping track of projects, their deviations from their expected courses and environments, and any measures to be taken to avert uncommon pitfalls. Prince2, PMBOK and CMMI tell you that this is the project manager's job. But in practice the project manager has often dug himself so deep into the project that he is unable take a "10,000 feet view" of the environment he's working in. That's why Risk Management is often forgotten. Project managers cannot do it themselves!
Do we rely on the bus driver to watch out for the thunderstorm?
I think most bus drivers already have enough on their mind simply to deliver their customers to the next stop. Likewise, project managers need to keep their eyes on the road. And they need other people and mechanisms to tell them that they might be approaching danger.
Well, these are just my thoughts. I think our industry needs to flesh this out some more...