​There are many misconceptions organizations fall prey to as they move from traditional predictive project management practices to agile product delivery practices. Some of these misconceptions are:

“We don’t need documentation, we’re agile!”

“We can’t tell you what you are going get until we deliver, we’re agile!”

“We don’t need to plan, we’re agile!”

While many of these misconceptions are resolved early in an organization’s agile transformation through training and coaching, I often experience one misconception that often goes unaddressed long into an agile transformation.

“We don’t need risk management, we’re agile!”

This misconception is not always said out loud but is demonstrated in the organization’s execution of an agile framework. A product team could go through several sprints or increments without ever identifying, analyzing, tracking, and/or responding to a risk that may threaten the delivery of the sprint’s goal. Too often it is excused with the justification that “missing a goal or objective is just an opportunity to learn, we want to fail fast”. While this is true could you have done something before-hand to increase the likelihood of meeting the goal or objective through sprint/increment execution?

Why is it that we catch other misconceptions early but do not catch this one until later, if we catch it at all?

To answer this question, we must acknowledge the hidden truth; that for the most part, organizations do not perform risk management well with traditional predicative project management approaches. Figure 1 illustrates the lost opportunities for risk identification. This is the necessary first step to perform risk management. If we do not regularly identify risks, we are not actively managing project risks.

Figure 1 – Depiction of Risk Management Process mapped to a Traditional Project Lifecycle, Source: MITRE

Many projects managed using traditional techniques stress maintaining conformance to the plan developed in the Project Planning and Preparation phase of the project life cycle. Development of the plan is usually done through investment of organizational time and expertise to reduce as much uncertainty as possible, i.e. reduce/eliminate risk to produce the “perfect” plan. Any risk that cannot be eliminated is identified and tracked. Once the “perfect plan” is developed and agreed to by the Project Sponsor, the project work is performed. We all know what happens when the “perfect” plan makes first contact with reality.

Deviation from the plan usually involves a change control process. This change control process is usually a well-intentioned process that involves some level of rigor, decision forums, and documentation that in the end discourages change to the “perfect” plan.

“If someone wants to change this plan, they better have a good justification.”

Early in the project, risk management is initially carried out with gusto. Risk identification is taking place, qualitative risk analysis occurs, a risk log is developed with several obvious risks and response plans developed where necessary. The response plans that are developed are typically mitigation strategies selected to reduce either the impact of the risk or the probability of the risk occurring.

Somewhere in the project “fog of war”, the Project Manager and team start to react to reality’s check on the plan. The project team begins to become overwhelmed with unexpected and unplanned events, make reactionary decisions in the moment and abdicate the discipline of risk management in lieu of “getting things done”. Risk Management is relegated to the last five minutes of an IPT (Integrated Project Team) meeting where risks are generally reviewed with little or no discussion.

In the end, we fail to effectively manage the project’s risks.

Is agile any better at risk management?

An agile framework such as Scrum is structured to provide multiple opportunities to perform risk management processes (risk identification, analysis, response planning, monitoring, and controlling) and to integrate the changes directly into the flow of the product delivery. Figure 2 depicts risk management processes mapped to an agile framework.

Figure 2 – Depiction of Risk Management Process mapped to an Agile Project Lifecycle, Source: MITRE

Whereas the traditional project lifecycle has long periods of work that do not have time for review, adaptation, and adjustment of the plan, Scrum has built in points for plan adjustment and reflection on the most recent product deliveries. The iterative and incremental nature of Scrum provides perfect pause points to execute risk management processes. For example, there are daily opportunities to identify risks (during the daily scrum), and bi-weekly opportunities (during Sprint Planning, review, and retrospective) of a two-week sprint cycle.

The key difference and often the reason for the misconception regarding risk management in agile, is the inherent ability to identify and manage risk quickly as a part of the iterative and incremental nature of the Scrum framework. In fact, the 2020 Scrum Guide explains as part of its foundational theory, “Scrum employs an iterative, incremental approach to optimize predictability and to control risk (Schwaber & Sutherland, 2020). This implies that by simply following the framework, risk will be managed.

The truth in this is “yes” risks are inherently managed through the nature of the Scrum framework, but this usually assumes a well-functioning single product team (i.e., self-organizing, transparent, good communication, customer, quality and results driven). Experience demonstrates that with a well-functioning product team, the response to risk is so fluid that it reduces the need for the monitoring, controlling, and tracking of risks through an active risk log or risk board. Most risks are directly addressed through adjustment/refinement of the Product Backlog by the Product Owner.

Keep in mind the above statement includes the assumption of a well-functioning single product team and only a reduction in the need to monitor, control, and track risks. It does not eliminate the need, especially when delivering product with a less than well-functioning product team. Organizations early in their adoption of agile may find it valuable to leverage the pause points in Scrum to carve out time to perform risk management activities.

When coaching a project through its agile adoption I have used tags or labels on a user story to connect items in the Product Backlog to risks in the Risk Register. While tags are physical connectors on a physical board, hyperlinks are just as easy to  insert in the “Description” area of an Atlassian Jira Issue. These hyperlinks can link the issue to a risk register that is maintained in a projects Confluence page (i.e., wiki page). Additionally the risks should have the corresponding story number(s) associated. This gives the team a view of how many user stories a particular risk impacts. This is just one option for tracking risks and connecting them to the Product Backlog. If using a product such as Atlassian Jira, there are several products available in the Atlassian Marketplace that are developed to support risk management within agile projects.

As organizations begin to scale their product delivery to multiple teams, the need for risk management is increased. Risk exposure related to product or team dependencies increases as product delivery scales up. These risks are usually related to product or team dependencies and may be captured and tracked in a risk log or risk board and require risk monitoring and controlling activities. Risks, such as not having business stakeholders engaged in Sprint Reviews can increase the risk that the team is building a product no one wants or a risk of not having the visibility into the Information Security Team’s backlog/ work queue can delay the release of the product to the user community.

The need for risk management at scale is exhibited by the explicit inclusion of Risk Management approaches in both the Scaled Agile Framework (SAFe) with “risk ROAMing” and the Disciplined Agile Delivery framework with its risk-value lifecycle approach (“maniacally attack risk early in the product lifecycle”). These frameworks offer different approaches to managing risks and include the identification, analysis, monitoring and controlling of risks, although in different ways.

When trying to figure out when and how to integrate risk management processes into an organization’s agile framework it is recommended first to develop an overall strategy for risk management. This Risk Management Strategy should be consistent across all products within the portfolio or organization in order to support a larger view of risks that may be impacting the delivery of more than one product. The risk management strategy should also provide enough latitude to allow the Product Managers to integrate the risk management processes into the framework as he or she sees fit. The risk management strategy does not necessarily need to be a formal document, it could be as simple as a “working agreement” maintained on a wiki page.

When adopting agile, include the visibility of organizational risk and the reduction of the risk to product delivery has one of the desired outcomes of the adoption strategy. Make it the mission of the Agile Coaches to embed risk management in the agile framework and have the coaches ensure that the risk management processes are carried out.

Risk management is not often talked about in agile communities and forums as Agilists also fall prey to the risk misconception. Even in scaled agile frameworks risk management is sometimes only given a light touch. An experienced Agile Coach will recognize scenarios that involve risk and will have response tactics that quickly recognize the risk, encourage the team to generate a response, and integrate that response into the flow of product delivery.

References

Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum Guides. https://www.scrumguides.org/scrum-guide.html

Disclaimer:  The opinions expressed here are those of the authors only and do not represent the positions of the MITRE Corporation or its sponsors.