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 at work, almost by definition, and often on the supra-project level.
So, how do we implement Agile Risk Management?
Well, you should 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 my experience, the project manager has often dug himself so deep into the project that he is not that good at taking a "10,000 feet view" of the environment he's working in. I think that's the main reason why Risk Management is often forgotten.
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 might need other people and mechanisms to tell them that they could be approaching danger. It's hard to see far ahead when you're too busy getting your bus out of a ditch you drove yourself into.
Well, these are just my thoughts. I think our industry needs to flesh this out some more...
Subscribe to this blog with a reader or by email!
Latest, greatest and favoritest posts:
Five Agile Competence Levels
The Agile Blind Spot
AINO: Agile In Name Only
