If managing risks with Agile could seem trivial in case of just one team, what are the good practices when multiple teams are working together building the same solution?
In the first part of this post, I explored how great is Agile at ts core and, more specifically, how Scrum implicitly and by design, takes risks into high account.
We know that risk management is mainly about culture. Whatever is the approach, technique, methodology used to handle risks, people shall be predisposed, educated and sensitive to it.
Risk culture is a term describing the values, beliefs, knowledge, attitudes and understanding about risks, shared by a group of people with a common purpose. This applies to all organizations. An effective risk culture, is one that enables and rewards individuals and groups for managing and taking care of the risks in an informed manner.
So, the first thing to do when in need of improving the way risks are managed within your organization, is to teach and train people on risks and how to manage them, then evolve the mindset by increasing transparency, trust and fostering a disciplined approach to risk management, again, whatever is the methodology applied.
Back to Agile, we know that Scrum teams manage actively impediments and are able to better foresee risks and implications. But how does this scale through a program of several teams working together on the same product? How risks are managed and escalated to the upper level?
It all starts with firstly enforcing the way risks are managed at team level.
Agile Risk Management Tools at Team Level
Scrum teams manage risks daily through the Daily Scrum. Additionally all the other events and practices (Planning, Review, Retrospective, Backlog Refinement) help them to identify, asses, evaluate and manage risks proactively and consistently, thanks to cadence and clarity of events, transparency of roles and responsibilities, team collaborative behaviors, etc.
Additionally, Scrum teams handle risks through lightweight approaches by using visual management and radiators, which maintain the information always visible and present to the whole team, asking for action.
The board above reported, helps teams to manage in their resolution and physically in one place both impediments and risks; for the latter, keeping also into consideration the different levels of attention.
However, in case of very risky and critical programs, a more robust approach in managing risks shall be applied; in those cases, the most disciplined agile teams used to measure, for each risk, two additional dimensions: Likelihood and Size of Loss.
Likelihood regards the likelihood that a risk can actually happen. Size of Loss measures the number of estimated days needed to recover and to get back on track if that risk eventually materialize.
The result of multiplying these two numbers, gives back the exposure for each risk, which can be added and accumulated for each sprint and, thus, reported over time. This assessment is done every iteration, according to Scrum events (Retrospective is a good one), in order to identify what actions can be put in place to mitigate if not definitely solve the risk.
The results of such actions, should lower, over time, the risk exposure. Risk Exposure trend can be then visualized through the Risk Burndown chart,
As we know, Agile teams are self-managing and self-organizing.
This means that they should always try to solve impediments and face risks, autonomously. When working in a program, it happens though, that some of these risks are more systematic, organizational and cannot be directly solved by themselves.
This is the time when teams shall escalate risks (in an agile way) to the upper program level. Let’s see how 🙂
Agile Risk Management at Program Level
Whatever is the Agile Scaling Framework chosen, Risk Management at program level follows similar rules described for Agile teams (fractal mode). Usually, when having teams working together to produce the same product/solution, we should have at least the following events (whatever the chosen framework):
- Inception and Release Planning
- Sync Events between team representative and Program roles during execution (e.g. Scrum of Scrums, Tribe/Train Sync, Nexus Daily Scrum, etc.)
- Program Demo and Retrospective
Risks are actively managed through this events.
One of the tool used which can be used is the same board above described for teams. Risks coming from that level and which relate to program, are pulled and here managed.
Risks are usually identified and assessed also during one of the events above reported. The Threat Matrix is also used at this level; this helps in assessing the likelihood and Impact of the risk…but always done in a collaboratively way by the teams and program roles:
Then every risk, according to its threat level, is discussed and managed by deciding which action must be taken. A good tool which can be used is the ROAM Board which groups risks into four categories:
- Resolved: no more a threat
- Owned: risks which need further investigation. An owner is assigned
- Accepted: risks whose level of threatness is very low, thus even if happening won’t impact seriously the program
- Mitigate: risks who are serious and thus are mitigated through punctual actions
…again visual management, involvement and cooperation between teams and program roles are key for the success of the activity and in general for risk management practice when you are playing the game in an Agile way.
Once a “traditional” guy told me: “when it’s time to manage projects and product development, Agilists like you are just cowboys which hug trees and hung post-its on walls”.
Well, we Agilists create the space where individuals and their great interactions meet lightweight processes and tools; this is when actually magic happens.
Wasn’t this the reason why Agile has been created?! :o)
