"How do we manage risks in an agile setting?" - Agile risk management differs widely from classic project risk management, because we have a different sphere of concerns. Whereas classical projects are mostly concerned with risks related to delivering within TQB (Time, Quality, Budget), an agile environment forces us to consider a much broader sphere of risks:

Agile risk management

There are some general notes on agile risk management that may be unfamiliar or in contrast to the expectations of classic project organizations:

Risk overview

Teams (and in SAFe, ARTs) should be able to have an insight into their most relevant unresolved risks at any time. The assumption is that "if there is no risk overview, there are no relevant risks." Scrum Masters ensure that both of these statements are true.

At a minimum, risks are identified as such to be visible. Some organizations prefer to add additional information, such as severity, occurrence, detection (the FMEA process) and countermeasures, which is only relevant if you have no means of addressing them swiftly.

Risks are treated like regular work items, and move into the backlog as "potential work to do". The teams decide whether new risks are added to the Sprint Backlog or to the Product Backlog - or to the Program Backlog, in a SAFe context.

Live updates

Agile risk management is a constant exercise of evaluating available information and anticipating probable events that should be avoided, then inspecting and adapting the determined course of action. Risk management in an agile setting happens during every event (and during daily work, as well) -

• Lean-Agile Budgets identify financial risks
• Refinement identifies product risks
• Planning and Dailies identify process, delivery and organizational risks
• Reviews and Demos identify delivery and product risks
• Retrospectives and I+A workshops identify all kinds of risks
• PMPO Sync identifies product and delivery risks
• Scrum-of-Scrums (SOS) identifies organizational and process risks

As such, the risk overview is a more volatile and shifting artifact than even the teams' plan, and potentially more ephemeral than the product backlog itself.

Avoid Single Points of Failure

Organizations are most resilient if there is no single points of failure, hence risk management becomes a collaborative exercise. It's better to work with focal areas than rely on a clearly delineated role-responsibility mapping. It is expected that everyone contributes to naming and resolving relevant risks, from the most junior developer to the most senior manager.

Scrum Masters facilitate team risk resolution and create transparency in the surrounding organization on those outside the team's control. Ideally, the team would be able to deal with their own risks even without requiring the Scrum Master to take action.

Risk resolution

Just as every day is an opportunity to identify risks, we should deal with them before they materialize, ideally right when it is exposed. It's the team's decision on how they will prioritize risks against other work.

Risks outside the teams' sphere of control should be adressed via proper channels. In a SAFe setting, the first channel for a team is usually from PO to PM or from SM to RTE who would involve management if required.

Focus Areas

Teams succeed by collaborating and helping each other out, so let's not go into the "sorry not my desk" antipattern. Still, people do different things, and so pay more attention to different aspects. In this context, let us examine the different focal areas of the common agile roles.

Product People risk focus

First and foremost, product people must take care that we build the right thing, and have the resources (both time and money) to do so. Hence, they must be aware of and deal with:

Financial risks

Financial risks are cash flow related. We must secure an initial investment that allows us to develop something, and in order to continue, we need ongoing funding. Within an enterprise, that's typically budget. On the free market, that's revenue, which is usually generated through sales or subscriptions. So the Product people need both the means to understand the current financial situation and to forecast the future, and thereby extrapolate wherein the risks lie.

Common financial risks include exploding license fees, stakeholders withdrawing their support, customers leaving or price wars on the market, but also pretty mundane stuff like equipment breaking down or the need for a bigger office as the team grows.

To manage financial risks, the product owner must understand their cash flow.

Since financial risks are entirely out of scope for classic Kanban, XP and Scrum, there tend to be no standard team-level mechanisms for dealing with them.

Lean-Agile Budgets are one of many SAFe mechanisms to keep the predictable financial risks away from the team.

Product risks

Product risks are related to success of the entire endeavour. We need to build the right thing right at the right time, and ensure we adopt to changing circumstances as rapidly as possible. Hence, "release fast, release often" is essential to minimize product risk. 

Common product risks range from building the wrong product over building it in a way people don't like all the way to the product becoming obsolete or unmaintainable. Hence, product risks can be located in the past, with consequences ranging far into the future. This requires constant attention both to the inner dealings of the team and the outside environment.

To manage product risks, it's essential to look beyond the backlog, into the product itself and the product's market. Metrics can serve both as lagging and leading indicators to discover and track their manifestation.

Refinement workshops, Reviews (System Demos) and Planning events should reveal product risks, both within the team and at scale.

Team risk focus

Autonomous teams have control over both their process and their delivery. Hence, the risks associated to these must be born by them:

Delivery risks

Delivery risks range from not delivering anything all the way to delivering the wrong thing or something that doesn't work, hence they include the huge topic of quality-related risks. Since delivery risks have a price tag attached, called the "cost of failure", these risks consist of more than pure impact - they also have a huge element of choice: we take calculated delivery risks when the benefit outweighs the cost.

Common delivery risks include defects, incidents and problems (in ITIL terms), not being in control over the product's technical quality, not testing right or enough as well as releasing something immature, but also failure to gather fast and reliable feedback that could expose and thereby prevent other risks.

Delivery risks must be managed, but often become visible in real time. They are hard to pre-plan.
If we see any delivery risk in the future, we should devise a strategy to start minimizing it today. Retrospectives address how we dealt with past delivery risks. Team dailies should reveal current delivery risks, and teams should actively collaborate to deal with them.
If they can't be dealt with immediately, they should be made transparent on the Team Board.

Process risks

Usually, a process risk manifests as an impediment towards doing the right thing swiftly. In larger organizations with strict regulations and massive dependencies, process risks are often outside the teams' sphere of control, which, in the worst case, may lead the idea of self-organization and team-level agility ad absurdum. 

Common process risks include handovers, bottlenecks, delays, but also technical aptitude.

Teams are expected to manage process risks within their own sphere of control. Where they lack this control, the Scrum Master must often intervene to drive risk resolution. 

Team Dailies often reveal immediate process risks.
Retrospectives are often the best point in time to deal with long-term risks.

In SAFe, we use the Scrum-of-Scrums and the I+A workshop to address cross-cutting process risks. Additionally, we can resort to Communities of Practice to deal with practice-related risks.

Scrum Master risk focus

One of the Scrum Master's core responsibilities is revealing the things nobody else sees - and that includes risks of all form and types. Sometimes, the Scrum Master actively has to examine risks from the other roles' focus to identify need for change. Additionally, there's a group of risks that will oftentimes require action on behalf of the Scrum Master:

Organizational risks

Organizational risks, in this context, are risks induced by the way the team and its environment is organized. Such risks occur within the team, at the interaction points between the teams and the surrounding enterprise, as well as imposed from outside the teams' immediate horizon. Most of them occur at friction points, that is, where incompatible parts of an organization collide.

Typical organizational risks include asynchronity, miscommunication, bottlenecks, communication gaps or inavailability of individuals as well as mismatching goals or priority conflicts. There is usually a positive correlation between organization size and organizational risks.

Two core activities where organizational risks are identified are Planning and Retrospectives. In SAFe, that would include PI-Planning and I+A workshops where the SM should feed in both input and track relevant action items.