Agile Is a Risk Management Strategy

Some people claim that agile software development is a risk management strategy.

Why?

Because all principles of risk management are nicely covered when you've implemented an agile process.

The International Organization of Standardization has identified the following principles of risk management in their draft of ISO 31000 “Risk management — Guidelines on principles and implementation of risk management”:

• "Risk management should create value."
  In agile projects (re-)assessment of business value, for prioritized user stories, is done in every sprint/iteration.
• "Risk management should be an integral part of organizational processes."
  When you're doing agile, you're doing risk management, therefore it is part of the standard process.
• "Risk management should be part of decision making."
  Every time you prioritize user stories, and every time you list impediments, you prioritize associated risks as well.
• "Risk management should explicitly address uncertainty."
  Uncertainty has been one of the main drivers behind the whole agile software development movement.
• "Risk management should be systematic and structured."
  A product backlog is systematic and structured. And the same applies to sticky notes with impediments on a task board.
• "Risk management should be based on the best available information."
  Meetings involve the whole team, including the Scrum Master and Product Owner, to maximize available information.
• "Risk management should be tailored."
  Retrospectives are meant to tailor the process on-the-fly, to match the environment and the project.
• "Risk management should take into account human factors."
  That's why risk management is done with all stakeholders, and not single-handedly by a project manager.
• "Risk management should be transparent and inclusive."
  The backlog includes all risks identified but not yet tackled. And the impediments on the task board are visible for all.
• "Risk management should be dynamic, iterative and responsive to change."
  Iterative? Responding to change? Now where did I hear that before? It had to do with a Manifesto, or something...
• Risk management should be capable of continual improvement and enhancement.
  Continuous improvement is what retrospectives are for, and it's at the root of everything that is agile.

You can see that all principles of risk management, as required by ISO, are covered by standard agile project management processes. Of course, it requires that risks are identified by both the customer and the team, and made visible on the backlog and the task board. This also fits well with my previous blog entry (Risk Management = Banana Peels AND Dollar Bills), where I wrote that risk management not only covers problems (impediments), but opportunities (user stories) as well.

Some examples of risk management could be:

1. If we don't finish user story A before deadline T the CEO is going to kill someone, and we will have to buy the CIO some flowers when he's in hospital.
2. We better assign user story B to this sprint, because Karl is the best developer to pick it up, and he will go on a 6-month vacation to Louisiana State Penitentiary next week.
3. User story C will deliver lots of business value, but that value will only be earned when we release it immediately after the marketing department finds out about the dead parrot.
4. The team must work hard to keep velocity at a high level, but there's a possibility some resources will be pulled away next week to fix the coffee machine in the executives wing.
5. The customer has not been able to review our latest demos, despite our efforts to beam the demo on the walls of the office building across the road.

 

Every risk identified by the team and the customer is either a user story or an impediment. Risks are evaluated in every sprint meeting and every stand-up meeting, and the team, the Scrum Master and the Product Owner take appropriate measures to manage them.

That's why agile software development is a risk management strategy.

However, I have also good reasons to claim that agile software development is NOT a full risk management strategy. But that's a story for next week...

(images by hellosputnik and the fayj)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
People Don't Listen
Three Levels of Control
How to Handle Many Simultaneous Projects