Did you anticipate the jellyfish or not?

Did you anticipate the jellyfish or not?

 

On February 12 at 5:44 AM a sink hole in Bowling Green, Kentucky opened up below the National Corvette Museum Skydome exhibit area swallowing eight cars. The risk of the sinkhole had not been foreseen; therefore no one had monitored the risk. The problem was discovered when a motion detector was triggered. The motion detector was in place to monitor and mitigate a more commonplace risk. I am convinced that the risk managers at the museum were convinced they had anticipated all reasonable risks. Every time methodologists, developers and project managers (of any stripe) decide that they have found the perfect process or method that risk-proofs their project that disaster is right around the corner. We have described how Agile mitigates some types of risks (Agile and Risk Management), however risk in general still needs to be managed and controlled in any size project. Software risk management is crucial to the success of all software development, enhancement and maintenance projects by avoiding problems that can be avoided and recognizing those that can’t be avoided. A lean process to manage risk in Agile projects is shown below:

  1. Identify knowable risks. – Identify the knowable risks when generating the initial backlog. Remember that risk identification, like the identification of users stories, will be an iterative process. Teams that have trouble identifying risks could leverage a checklist or a list of common risks.
  2. Build mitigation for common risks into the definition of done. – The definition of done is the requirements that the software must meet to be considered complete. Common risks such as the failure of the software to integrate properly can be built into the definition of done, which provides mitigation for the risk.
  3. Generate stories for less common risks and add them to the projects backlog. – Risks that can’t be mitigated and monitored through the definition of done can be treated as a specialized form of a user story and added directly to the product backlog.
  4. Review risks when grooming stories. – Just identifying and listing risks is useful, but not sufficient. It is necessary to review the risks placed on the product backlog.  The backlog grooming process provides a good platform for periodic risk review to ensure that if a risk needs to be mitigated steps can be added to the next sprint or that if risks are becoming issues that steps can be taken immediately.
  5. Carve out time during planning to identify emerging risks. – Project environments are dynamic. New risks may emerge or current risks evolve as the project progresses. Carving out time to reflect on risk as part of planning will help the team avoid being surprised.

Why is the discussion of risk important? Projects need understand what can reasonably happen and be prepared. While very few projects would have to plan and prepare to deal with a sink hole opening up and eating their data center or the project team (unless they were in Bowling Green) potential risks that are reasonable should be anticipated. In a world where most projects are integrated into an organizations value chain, potential disruptions or failures need to be explored and monitored.

Advertisements