Agile Risk Management refers to the way agile projects manage risks. Comprehensive frameworks for predictive projects, such as the standards of the Project Management Institutes, suggest a number of processes, tools and techniques to manage project risks. Many agile frameworks tend to be more light-weight which is part of their charm but requires agile teams to come up with their own risk management approaches.
This introduction provides you with an overview of common ways and good practices to identify, measure and manage risks in agile projects.
What Is Risk in an Agile Project?
The Project Management Body of Knowledge which contains the Project Management Institute standards (source: PMBOK, part 1, ch. 11, p. 397) distinguishes risk into to different types: Individual project risks that have a positive or negative impact on project goals if they occur, and overall risk that would affect the project as a whole.
Agile projects often aim to incorporating project goals more intensely than traditional projects. In a daily Scrum, for instance, team members might answer the question ‘what have I created since the last meeting’ and ‘which impediments am I facing’ with reference to the project goals (or sprint goals, to be precise). Teams and team members in waterfall projects might tend to focus on their own areas and deliverables they are individually responsible for.
While this may smoothen the management of individual risks in agile projects, it does not necessarily so for the overall project risks. In particular if they are external to the project – e.g. social, technological, economical, environmental and political risks (STEEP) – an agile project is probably quicker to react to their occurrence. Yet, it also needs to manage these risks in advance as the flexibility to react might not be sufficient.
For instance, agile project teams are able to quickly adapt to stricter regulatory requirements for the software or service they produce. However, the risk exposure to other overall project risks is not necessarily different from traditional projects – e.g. if this service or product gets prohibited entirely or if their office building burns down.
Background of Agile Risk Management
Risk Management in agile projects differs from traditional risk management in predictive types of projects. This is because of the shorter development cycles and the less planning-focused methodology of agile approaches. Thanks to the improved collaboration between the business and the execution or development sides and the regular refinement of requirements backlogs, many types of risks are less likely to occur while the project is able to react quicker to issues and threats.
However, this does not suggest that agile projects are entirely risk-free. It only implies that different approaches to the management of risks are needed that take the characteristics of these types of projects into account.
How Risks are Managed in Agile Projects
Most agile frameworks do not contain dedicated risk management processes given as they are focusing on quality as a built-in element of agile development processes. Tools and techniques such as early feedbacks, joint business and IT teams, pair programming or testing as a central or even driving part of the development process aim to increase quality and thus reduce internal risks.
These approaches are quite effective to maintain quality and avoid fatal issues in late stages (as they could occur in waterfall projects, e.g. if fundamental malfunctions are only detected in the testing phase, almost at the end of the project).
However, they might not entirely address external risks a project is exposed to. These may include environmental, political and legal risks (e.g. if elements of the product are subject to regulatory requirements), for instance. While these risks may be impactful on projects of all different sizes, the risk exposure becomes even more complex for agile projects of a larger scale, such as Scrum-of-Scrums or Disciplined Agile.
Although there is no generic or prescriptive approach to risk management in agile projects, it has become a good practice to leverage on some processes and techniques of traditional project risk management.
With reference to these frameworks, risk management for agile projects consist of the following steps:
- Risk identification,
- Risk assessment,
- Risk responses, and
- Risk review.
In predictive projects, this is often done during the project set-up and updated on an ongoing basis during the entire project lifecycle. In agile projects, these steps are performed at least once for each iteration, and updated during the development cycle. Regular communication within project teams, such as the daily stand-up meeting in Scrum, facilitate the quick identification and assessment of risks.
Let’s look at the details of each of these steps:
Risk Identification
This step requires the team, the project manager or an equivalent role and the business side or product owner to identify potential risks for achieving the project goals.
While this is initially done in meetings, using the typical agile information gathering tools and techniques, it is also incorporated in the daily project work.
In Scrum, for instance, one of the topics discussed in daily Scrums relates to potential impediments (i.e. risks) team members are expecting for their respective next step.
Risk Assessment
As in traditional projects, risks are evaluated by the probability of occurrence and the impact they might cause if they materialize. Projects typically use a matrix to assess the value of these risks which is a basis to come up with risk responses and prioritization.
Risk Responses
The risk responses are potential or actual strategies to deal with positive and negative types of risk when they occur. Assigning responses to the most relevant risks is a good practice in both traditional and agile projects. The project management methodology (PMBOK, part 1, ch. 11.5.2.7, p. 445) defines the following response strategies for overall project risk:
- Avoid
- Exploit
- Transfer / share
- Mitigate / enhance
- Accept
While project risk management in waterfall projects tend to focus on planning which includes avoidance and mitigation strategies, agile approaches embrace the learnings and the required changes that may stem from (small) failure. A good example of a ‘doing rather than planning’ mentality is the quick initial development of potential solutions to a requirement in order to explore its feasibility. Some frameworks explicitly suggest the development of these so-called ‘spikes’ to test different options and, thus, reduce risks.
Risk Review
Risk reviews comprise the check and review of identified risks and issues. A result can be the re-adjustment of impact and probability assessments or the re-assignment of potential risk responses. Risk reviews are ideally done on a regular basis, at the least at the start or end of a development cycle.
Tools and Techniques of Agile Risk Management
The tools and techniques used in agile risk management include yet are not limited to:
- Risk Burndown Chart
- Risk Register or Log
- Risk Modified Kanban Board
- Risk Probability and Impact Matrix
- Prioritizing Backlogs based on Value and Risk
- Identifying / Discussing Risks in Regular Meetings (e.g. Daily Scrum)
In practice, there are plenty of tools, techniques and approaches to manage and monitor risks in an agile project. In fact, every agile project follows a somewhat unique approach in terms of how and to which extent they decide to deal with risks. This is in line with what agile frameworks given that their aim is not to be prescriptive methodologies.
Difference to Risk Management in Waterfall Projects
Agile projects generally aim to produce usable or shippable results, that are parts of the overall project goals, as quickly as possible. They also integrate business representatives in their development team and promote early testing as a measure of ongoing quality assurance.
This implies that failure (as one kind of risk) is detected within a short period of time. As agile approaches embrace changes and require only light-weight planning, a project can therefore adapt to the requirements and implement the corrective measures comparatively fast.
Refer to the following summary for a comparison of these aspects with risk management in traditional approaches (read more on dummies.com):
Risk Management in Traditional Project Management Methodologies (in a Nutshell)
- Longer development and planning cycle that increases complexity and therefore individual project risk
- In waterfall projects: Testing at the end of the project which may delay the identification of occurred risks
- Less responsive to changes due to change management processes and planning constraints
- Prescribed comprehensive processes to identify, assess and review risks and assign risk responses
Risk Management in Agile Projects (in a Nutshell)
- Short development cycles and quick delivery of increments aims to reduce complexity and risks
- Testing is part of the development cycle and business people are often part of the project or development team which reduces risks
- High responsiveness to changes
- Most frameworks do not prescribe risk management processes and techniques which requires the project team to select and adapt adequate measures
Conclusion
Agile project frameworks are generally less prone to internal or project-individual risks thanks to their built-in quality measures and their responsiveness to changes. However, agile projects need to identify, assess, monitor and review external risks similarly to traditional projects.
Without prescriptive processes and techniques, it is the agile team’s (and stakeholders’) responsibility to agree on the extent and granularity of their risk management. Apart from the identification and assessment of external risks, agile teams should at least reflect on potential risk responses to the most relevant risks.