Agile Risk Management

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

  • List of All My Articles
  • FREE Copy of The Software Practitioner
Related Posts
free book
“How to Change the World”
  • Daan
  • Jurgen Appelo

    “That’s why ‘risk management’ is not important anymore. […] That’s why you have short iterations, involvement of the customer, and other practices.”
    Daan, it is true that agile practices are designed to mitigate some risks. But they definately don’t replace risk management. I can easily prove that.
    Kent Beck, Ken Schwaber and the other experts admit that there are some requirements to be met in order for agile projects to succeed. (For example: technical excellence, experienced/motivated people, customer availability.) What if there’s a risk that any of these requirements aren’t met?
    You have a logical fallacy on your hands if you think that the existing agile practices are able to fix themselves to mitigate any risk.
    Following your reasoning, three dead people and a cow would magically transform themselves into a successful agile team!

  • Daan

    My reasoning is: don’t add another process. Improve the existing process until it gets better. For example: the customer doesn’t get what he wanted. Why? Do a retrospective and improve your existing process.
    I didn’t say that agile practices would fix themselves. Practices don’t fix themselves, people do. ‘Risk management’ is just another set of processes to make sure people will do their job. Again: don’t add another process. When you just throw more processes at any given problem, it will give you in the end a ‘control’ culture with bad metrics, people that don’t trust each other, bad productivity, unmotivated employees, bad quality, management by numbers, etcetera. I’ve seen it happen in a big company, and it was not pretty.
    I think Risk Management is not necessary if you practice continuous improvement with a responsible team.
    The Agile Manifesto says: ‘Individuals and interactions over processes and tools’. People are more important than processes.
    Trust people, not processes. Keep thinking on how to improve. Give people the power and responsibility to improve.
    About the three dead people and the cow:
    “Build projects around motivated individuals.
    Give them the environment and support they need,
    and trust them to get the job done.” —
    So, you need motivated individuals. Dead people are not motivated and can not communicate or write code. Common sense. If you don’t have motivated people, you’re lost. Even in that case, extra processes will not help, because you’re already screwed.
    To counter the example: “Three dead people and a cow would magically transform themselves into a successful team, if you ‘manage the risks’ properly!”

  • Jurgen Appelo

    Daan, I think you completely missed my point. I’m not talking about adding processes. I agree with you on that.
    But you cannot simply put a number of people, a customer and an agile handbook in a room and expect them to deliver a good product.
    Like you said, you need motivated people. Agile won’t help you when you don’t have those. Indeed, You’re screwed then…
    UNLESS, you have someone acting on a “meta-agile” level, who is watching for potential problems in projects, and can act accordingly.
    That, to me, is Risk Management.

  • Daan

    “UNLESS, you have someone acting on a “meta-agile” level, who is watching for potential problems in projects, and can act accordingly.”
    I have no idea what flavor of ‘agile’ you’re using, but this sounds like a Scrum Master’s role, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. For me (coming from the Scrum side), Risk Management is overkill if you have a good Scrum Master.
    What agile methodology do you use?

  • Jurgen Appelo

    We pick and choose from all methods, but mainly from Scrum.
    Sure, ScrumMasters (in our case Project Managers) should do most risk management. But we’ve come full circle now, as I believe (as a manager) that some ScrumMasters have a hard time smelling the potential problems. Particularly when they get involved only after the contract has been signed.

  • Daan

    IMHO a Scrum Master is very different from a Project Manager (but that’s a different story).
    To sidestep a little: I think it’s very hard if you have a fixed contract, to deliver quality software. We have Scope, Quality and Timebox. If you’ve signed the contract, you probably agreed on the Scope and the Timebox. That leaves only Quality to be variable. And, because you signed a contract where you promised to deliver, you have all the risk.
    Because your customers are not agile, it’s hard to get on without hard agreements on scope and timebox. That’s how it works (not how it should work).
    We’re currently working together with another company that does software development for us. We do not have a fixed scope for them, only hours are billed. We are the product owner, we work together to make something beautiful. That requires a great deal of trust and involvement. On the other hand, it gives much flexibility, good teamwork and great software. We are very happy with how it works out (as a customer). Maybe you can ‘teach’ customers how to be agile? 🙂

How to Change the World - free Workout - free