Shared Risk Management

I wrote this post over 4 years ago while working for Laterooms. The idea was to publish it in Laterooms engineering blog but for some reason or another it never happened. The intention was to document the way we managed risk in an Agile environment and how the technique we describe and experimented with impacted delivery.

Problem Statement 

Our team was finding a great number of unmitigated issues mid-sprint that had not surfaced during sprint planning, not because the planning sessions were not being rigorous, but because risks were not being identified and mitigated ahead of time.

We needed to get a better understanding of what types of issues and to what degree they were affecting our progress. Up until this point, as a Product Owner I had owned our RAID, logging all of the risks and issues, qualifying them for impact and trying my best to mitigating them to the best of my abilities.

The more we got entrenched into Scrum, the more I realised this was an agile anti-pattern, no individual person is able to identify and mitigate a wide range of potential risks that affect a product team. Identifying and mitigating issues had to be made a collective goal, shared and owned by the entire team.

Qualifying Risks and issues

The first step was to make sure all of the risks and issues affecting the team were logged, by collaborating with the team, using our Systems Context diagram to map out all of the different systems surrounding the team we quickly realised that we had a lot more risks that we initially thought.

We now needed a way to qualify the risk and issues, so we decided to use a common scale that would allow us to overlap risks and issues with velocity, providing the a full picture of how RAID impacts the teams progress.

Improved Visibility

Our Risks and issues board is visible to the team at all times, we booked in a weekly stand up where the entire team goes through the risks inventory and assess the impact and probability of each risk.

When Risk Management becomes a shared activity, it is owned by the team and becomes part of the organic process. Teams get used to looking at the information radiator and begin to use it as an indicator of what is ahead.

We use our risk board similarly to what the Dashboard of an airplane, our dashboard gives us a visibility of any potential risks ahead of our journey giving us time and space to make informed decisions on what to avoid any potential obstacles/dangers that lie ahead.

We then surfaced the risk board in a burn down chart where X is the effort required to mitigate the risks, y is the estimated loss should the risk convert into an issue. The key objective is to use this tool to prevent risks from becoming issues that would inevitably hurt delivery. 

Observation

Unsurprisingly, shared risk management clearly showed that we have a lot more issues impacting progress than we thought. Most issues have dependencies that have been identified, since we now know ahead of time are, and how they impact velocity, we now know what areas we need to focus on.

Benefits

  • Made all of the issues impacting the teams progress visible,

  • Surfaced risks that would have gone unnoticed,

  • Able impact of issues and unmitigated risks on Velocity,

  • Highlighted recurring areas where dependencies emerge,

  • Improved sprint Planning – Less unknowns,

  • Increased the efficiency of the mitigation of risks as they are identified when the probabilities still low. 


I highly recommend that you checkout the Laterooms engineering blog, particularly if you are interested in the implementation of Elastic Search
For further reading Elastic, the iCarAsia Engineering team has a great series of posts that cover how use Elastic Search to improve our consumer experience.