Risk management is about identifying, addressing, and eliminating sources of risk before they become a threat to the project. This article outlines traditional risk management, how Agile is a risk mitigation strategy, and how to do Agile risk management.
Traditional Risk Management
Project Risk Management is one of the nine project management knowledge areas in the Project Management Body of Knowledge (PMBOK) from the Project Management Institute (2004).
Generally risk management means:
- Risk identification – make a list of the risks that threaten the project
- Risk analysis – assess the likelihood and impact of each risk
- Risk prioritisation – identify the significant risks based on likelihood and impact
- Risk-management planning – plan how to deal with each significant risk
- Risk resolution – execute the plan, i.e. deal with each significant risk
- Risk monitoring – monitor execution of the plans to deal with each significant risk and continue with risk identification
How Agile is a Risk Mitigation Strategy
Steven McConnell (1996) adapted the work of Boehm (1989) and Jones (1994) to produce a list of the most common schedule risks in software development projects. The common risks are listed in the following table along with an assessment of Agile’s impact on that risk.
| Common Risk (from McConnell, 1996) | Agile’s impact on risk |
|---|---|
| 1. Feature creep | Reduce |
| 2. Requirements or developer gold-plating | Reduce |
| 3. Shortchanged quality | Reduce |
| 4. Overly optimistic schedules | Reduce |
| 5. Inadequate design | Possibly increase |
| 6. Silver-bullet syndrome | Increase |
| 7. Research-oriented development | Reduce |
| 8. Weak personnel | – |
| 9. Contractor failure | – |
| 10. Friction between developers and customers | Reduce |
Good Agile Project Management reduces risk by directly addressing several of these common risks. Unfortunately, Agile potentially increases some of the common risks. On balance Agile reduces more risks than it introduces … if you do it right.
Agile Reduces Feature Creep
Feature creep is the uncontrolled addition of requirements to the scope of a project. As scope increases so does the cost and the chance of delivering diminishes. Notice that feature creep is about increasing scope, not about changing scope.
Having clear Agile Roles and Responsibilities means the project has a product owner and a project manager. These roles work together to ensure the scope doesn’t creep. The mechanisms are Agile Project Planning and Agile Change Management.
Agile Change Management means when the product owner asks the project manager to add a feature to the scope they use requirements trade off to ensure the overall scope, and hence total effort, is unchanged. The scope changes but the overall scope is stable in terms of effort.
Agile Project Planning ensures that the high priority requirements are delivered first. The product owner is continuously expected make priority calls and moves the important items to the top of the list. Low priority items are put to the end of the plan and if the schedule doesn’t have space these items are put out of scope.
Agile Reduces Requirements or Developer Gold-plating
Gold plating is the process of embellishing a component beyond the needs of the project. Requirements gold-plating is when a product owner adds attributes to a feature beyond what is strictly necessary for project/product success. Developers can also gold-plate; this is when they keep polishing the code for a feature to make it perfect rather than just functional.
Gold-plating is really hidden feature creep so, as with feature creep, clear Agile Roles and Responsibilities, Agile Change Management and Agile Project Planning can counter act this risk.
Agile Discourages Shortchanged Quality
Every project can trade off between scope, cost, time and quality. For example, if there is a hard launch date, the business might demand we fix scope and take technical short cuts (i.e. sacrifice quality) to make the target date. This is a short term strategy with big long term costs, but is none-the-less depressingly common. Fixing scope and flexing quality, despite being a common strategy, is contrary to the dictates of Agile.
Agile makes the trade off between scope, cost, time and quality explicit. Agile explicitly fixes time, cost and quality. The only dimension that is expected to change is scope, so if a project is threatened with an overrun then features are dropped rather than extending the time, throwing more money at the project, or cutting corners and reducing quality.
Agile Fights Overly Optimistic Schedules
The schedule has requirements mapped to time based on the team’s capacity to deliver. Agile Project Planning uses Agile Estimates and measured velocity to put together an empirically sound schedule. Things can still go wrong, particularly when guessing the initial velocity for a project, but measuring velocity on an on-going basis means you will soon realise that you are being optimistic.
Agile Can Lead to Inadequate Design
Scrum was invented within a internal product development basis so in a sense the Scrum process doesn’t cover the entire project life cycle, just the bit once the project is in flight. This means there is a danger of doing insufficient work, including design, before development starts in earnest. In other words, following the official form of Scrum will heighten this particular risk.
Other Agile methods do have an upfront stage where design can happen – XP has Iteration Zero and DSDM has the Business Study. The difference in Agile, however, is that design isn’t seen as a one off event, but an on-going process. Even with some upfront design the design activity is expected to continue into development.
Agile Can Lead to Silver-bullet Syndrome
Agile is often seen as a silver-bullet so increases this risk.
Agile Can Cope with Research-oriented Development
The empirical nature of Agile Project Management means that the risk of running a research-oriented project is reduced. Agile Project Planning uses Agile Estimates and measured velocity to put together an empirically sound schedule.
Agile Doesn’t Address Weak Personnel
Agile does not affect this risk. It is as true in Agile as in Traditional development.
Agile Doesn’t Address Contractor failure
Agile does not affect this risk. It is as true in Agile as in Traditional development.
Agile Reduces Friction Between Developers and Customers
Agile reduces this risk. Familiarity reduces friction and Agile encourages interaction between developers and customers.
How to do Agile Risk Management
Agile does not dictate a risk management approach – DSDM is the only Agile method that does – but as discussed above Agile is a risk mitigation strategy in itself, and several of the Agile practices make traditional risk management easier. The project manager is responsible for risk management.
Agile Risk Identification
Risk identification is about making a list of the risks that threaten the project – the risk log. All project members are expected to identify and report risk as part of their role but the project manager owns the risk log. Several Agile practices facilitate risk identification.
The daily meeting (whether Stand Up or Scrum) highlights impediments to the project – either risks or issues. Many of these can be dealt with by the team immediately. Those that can’t get logged by the project manager and are addressed outside the meeting.
The collaborative nature of Agile Project Estimating means there is more likelihood of identifying risky elements at the start.
The empirical nature of Agile Project Planning and Agile Project Control ensures capacity (i.e. velocity) is continuously recalibrated and so threats to the scheduled highlighted early. This recalibration happens at least once per timebox.
Agile Risk Analysis
Risk analysis is the process of assessing the likelihood and impact of each risk. The project manager can do the ratings themselves or get a specialist to do it. I like to rate both on a simple scale from 1 (low) to 3 (high).
Agile Risk Prioritisation
In risk prioritisation you identify the significant risks. I calculate the risk exposure by multiplying the likelihood (scale of 1-3) by the impact (also a scale of 1-3); this results in a value from 1-9. Any risk with a risk exposure of 6-9 is a significant risk that you need to manage. Risks with a risk exposure of 1-5 are not worth managing.
Agile Risk-management Planning
In risk management planning you decide how to deal with each significant risk. The approach taken will vary depending on the nature of the specific risk, but generally speaking there are four approaches to risk management planning
- Risk retention – basically means accepting the loss when it occurs. Only do this if the cost of addressing the risk is greater than the impact of the risk.
- Risk avoidance – avoid the risk by not doing the activity that carries the risk.
- Risk reduction – any method that reduces the impact or likelihood of the risk, hence the risk exposure.
- Risk transfer – get somebody else to accept the risk.
Agile offers some risk management techniques.
- The collaborative nature of an Agile team means that the team can share responsibility for resolving a particular risk.
- Agile advocates bringing risky requirements forward in the schedule. This means there is more time to assess the risk of the item and to identify feasible solutions.
- Agile also promotes the idea of investigating risky requirements. Whether called a feasibility prototype (DSDM) or a spike (XP) this means spending some time technically investigating the requirement and related technical issues and solutions.
Agile Risk Resolution
Risk resolution means executing the risk-management plan, i.e. deal with each significant risk.
If the Agile team has to do anything to resolve the risk then it has to be factored into the plan. Agile Project Planning means all work for the Agile team appears either on the Release Plan as requirements and/or the Timebox Plan as tasks.
Agile Risk Monitoring
The project manager must continue to monitor the risk-management plan dealing with each significant risk. Any work involving the Agile team will be in the Release Plan and/or Timebox plan. The project manager must, however, also monitor risk-management plan for risks that are being dealt with outside the Agile team.
Finally, the project manager also needs to continue risk identification which takes us back to the beginning of the risk management cycle.
References
Boehm, B. W. (Ed). (1989). Software Risk Management, DC: IEEE Computer Society Press.
Jones, C. (1994). Assessment and Control of Software Risks. NJ: Yourdon Press.
McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules. Microsoft.
Project Management Institute. (2004). A Guide to the Project Management Body of Knowledge (PMBOK Guide) [3rd Edition]. Author.
Pingback: Agile Risk Management | Bart Vermijlen
Pingback: HansKohls.com » How do you communicate risk?
Pingback: Handing off a project to a client; what are the risks and challenges? | Pragya Rana's Blog
Pingback: Top 5 Traits of SAP Project Managers - ERP, Cloud & Business Transformation Blogs