A risk is something that can occur and cause unexpected outcomes which can be positive or negative. In general, when risks are being discussed in relation to Agile risk management there is a lot of crossover to traditional project management.
Traditional Risk Management is done up front and tries to envision what could go wrong all the way to the end of the project. Agile Risk Management is done more by practices then envisioning. Many Agile practices look to identify and mitigate risk throughout the project.
- Traditional vs Agile Risk Management
- 8 Common Risks in Agile Management & How to Prevent Them
- 4 Agile Risk Management Tools
Traditional vs Agile Risk Management
Project Risk Management is one of the 9 management knowledge areas in the PMBOK® which uses a risk register to document risks. The process in traditional project management would be the following:
- Risk Identification (Identifying risks to a project)
- Risk Analysis (Analysing identified risks)
- Risk Prioritisation (Identify high priority risks)
- Risk Management Planning (Plan risk responses)
- Risk Resolution (Execute plan)
- Risk Monitoring (Continuous risk identification and analysis)
Risk identification will utilize qualitative risk analysis to create a risk register. The risk register is then used to start prioritizing the risk
Risk can be categorised into the following:
- Business (Related to business value)
- Technical (About technology use and/or skill sets)
- Logistic (Related to schedule, funding, staffing, etc.)
- Others (Political, Environmental, Societal, Technological, Legal or Economic (PESTLE))
8 Common Risks in Agile Management & How to Prevent Them
McConnell created a list of common schedule risks in software development based on work originally done by Boehm and Jones. He proposed that the projects risk can be reduced by directly addressing these common risks:
Feature creep is uncontrolled addition of requirements to the scope of a project. Having a Product Owner to protect the project’s scope by using Change Management
Gold plating is when a feature is delivered excelling requirements. A Product Owner should prevent this as they should know what the team is working on.
This is referring to making short-term changes to meet a target or deadline. Agile makes the trade off for scope, cost, time and quality explicit. Time, cost and quality are fixed in Agile and Scope is the only variable so features should be dropped instead of quality to meet a deadline)
Overly Optimistic Schedules
Requirements should be mapped to capacity based teams delivery of story points per iteration. The team’s velocity should be constantly monitored and adjusted based on data.
Scrum does not cover the full project lifecycle and works best for implementing software as there is no single design phase prior to the work starting. This can lead to a risk of inadequate design.
Silver Bullet Syndrome
Just because a project is using Agile does not mean it is destined for success, Agile projects fail too.
The empirical nature of Agile means the risk of running a research orientated project is reduced
Agile teams can equally consist of weak personnel similar to traditional project management. How to Handle Poor Performance of a Project Management Team.
4 Agile Risk Management Tools
Agile Risk Register
A risk register is a collection of all risks in a project and would include the following fields:
- Description of risk, Date Identified
- Probability, Severity, Priority
- Owner, Action, Status
The agile risk register should be updated during sprints and reviewed at each sprint planning session to ensure any risks need to be prioritised for next sprint.
Risk Adjusted Backlog
This is when the Product Owner prioritises stories on a backlog based on the risk associated with the story. If a risk has high probability and impact on the project it would be prioritised high on the backlog but if the risk had a minimum impact and probability of happening it will be lower in the backlog.
Risk Burn Down Graphs
A risk burndown chart demonstrates the total amount of risk associated with the project and risks eliminated per iteration. It provides a high-level overview of how many risks present in the project at a given time. It would be expected to linearly decrease over iterations.
A risk-based spike is used to allow the team to eliminate or minimise a risk. If a risk-based spike fails for every possible approach the project reaches a condition as “fast failure” where the cost of failure is away less than failing later. More information on risk-based Spikes from the Agile Dictionary