A prevailing belief among Agile and Scrum proponents is that “a great deal of explicit risk management becomes unnecessary when a software development project uses an agile approach.” In my experience, this is a false and dangerous assumption. Project risk is a hungry leopard ready to devour the unprepared. Fleet-footed agilists and die-hard waterfallists alike.
Author: Richard Payne, Connect2Learn, Inc., www.connect2Learn.com
While it may be true that one software development method has advantages over another in a particular situation, it doesn’t follow that we can generalize that any method automatically mitigates risk better than another. While we can agree Scrum minimizes certain risks in an ideal deployment, it also exposes the project to a new set of risks. At the end of the day, it’s more of a risk swap than true mitigation. To the surprise of many, a waterfall methodology in a regulated industry may do more to mitigate risk than a Scrum-based approach. It’s impossible to say for sure unless we look at project specifics. And believing any software development approach automatically mitigates the need to explicitly assess and track risks is certainly a risk itself.
Throughout the life of a software development project, large external risks frequently fail to materialize while seemingly insignificant risks wreak havoc. The job of the project manager or Scrum master is to identify risks whenever deploying a particular methodology in a specific project environment. The bottom line is that the project manager, product owner, or Scrum master, must identify and assess the relevant risks that can impact their project.
The recommended process for identifying and managing risks is as follows.
1. Identify and Document Candidate Risks: At project onset, a risk assessment should be made and documented. Examples of the types of risks to be considered are listed below. It’s recommended that a ‘risk workshop’ be conducted with representative members of each stakeholder group as well as senior developers to identify candidate risks.
2. Qualify and Quantify Project Risks: Each risk must be considered. To qualify a risk is to determine its relevancy to the project. Some risks may exist, however, their relevance to the project may be at such a low probability that no action is warranted. Once a risk is determined to be relevant, then it must be quantified. To quantify a risk is to determine the scope and scale of its potential impact, typically in terms of a loss event (lost time, lost productivity, failure to meet requirements, etc.). This information would be highly valuable when planning a sprint or laying out a project plan.
3. Establish Risk Indicators: For each risk, identify the ‘trigger conditions’ that would indicate the risk is becoming greater or less. These triggers can be monitored in the daily huddle. For Scrum projects, the Scrum master can maintain a burn-down chart on known risks, while realizing that new risks will often emerge. For traditional software development teams, this information should be monitored via the project’s Risk Management Log.
4. Develop a Risk Mitigation Plan or Strategy: Each risk will need specific response or mitigation. Typically, there are four methods of reducing risk – terminate (eliminate the root cause of the risk), tolerate (accept the risk), treat (mitigate and reduce the risk), or transfer (move the risk so it doesn’t impact the project).
5. Monitor Risks: Throughout the life of the project, risks must be assessed on a routine basis. At a minimum, a weekly review is required. For Scrum projects, the Scrum master has the benefit of daily information feedback, and should consider risk impacts as status information is shared. For traditional software development projects, risk review should be a standard component of routine status reporting.
The three typical categories of risk are:
External Risks. These are risks that the project team has little influence over, but could have an impact if they occur. These include Financial, Strategic, Operational, Reputation, and Hazard (Disaster). Typically, the project manager demonstrates awareness of these risks but is unlikely to have a risk management plan for them.
Project Risks. These are risks that can be identified at project onset and can be monitored for the length of the project. Typical categories include project size and scope, it tools and methods, project organization, project management, project operating environment, business process/application environment, business requirements, cross organization factors, technology – hardware, software, and unique project specific risks. Typically, the project manager has gone through a formal identification and assessment of these risks and determined which of them are actionable.
Application Risks. People, Process, Technology, and Environment – these are risks that occur in the application environment as the project progresses from requirements to design to build to deployment. These are assessed risks as the solution takes form.
Lastly, one must remember that risk comes in three flavors.
Upside Risk. Something ‘good’ that happens and impacts the project for the better. For example, an unforeseen technological breakthrough could accelerate the project but still create pressure to implement sooner.
Downside Risk. Something ‘bad’ that happens and impacts the project for the worse. For example, a key vendor withdraws from the project because of contractual or financial concerns. This would be a ‘loss’ and would negatively impact the project.
Variable Risk. Something happens that could be good or bad. For example, the addition of development resources to a project that is behind schedule. This may be good (we get more resource) or it could be bad (they have no training in the technology or application).
To wrap-up, no methodology is an antidote to risk. Risk management is the only proven approach and the more refined and objective it is, the more likely the risk can be diminished, although never eliminated completely.
All of these risks exist regardless of what methodology is deployed. It’s the probability and impact that is affected by the methodology choice, not whether the risk exists. Whether a project team uses agile, DSDM®, waterfall, hybrid, spiral, rapid application development, or simply goes for it, risks always exist, and some of them will impact the project. You can’t change the spots on a leopard.
© 2013by Richard Payne. Permission for reprint and web distribution granted to scrumexpert.com
Author Biography
Richard Payne is a Consulting Partner and Founder of Connect2Learn, a firm providing training in risk management, project management, business analysis, and software testing. He has worked in Information Technology since the mid-1970s but remains focused on emerging software development techniques.