Getting Software Teams to Manage Risk

As we have seen in other blog posts, bespoke software development for any business carries with it great risks – many of which can often be unknown to the business. That is not the point of this post! This post is about risks that are known to the business, yet they remain ignored and without a plan for mitigation, leaving the business in a world of hurt – unprepared and reactive at the moment least expected.

So how do you know if you’re walking into ‘Egypt’? That is, a business in denial.

The easiest thing to look for are the three most common symptoms of denial:
1 lack of process
2 lack of visibility
3 lack of ownership

So how do the teams know what their risks are? The risk register can be fancy, but at it’s core, it is a simple document with four columns as follows:

Risk		
Likelihood (some kind of rating)	
Impact (some kind of rating)		
Mitigations	

The first column is ‘Risk’ which is articulating the risk in words both the team and leadership can understand. An example of a risk would be: “Integrating Tensorflow models into our application is something new, so may affect our estimation”

‘Likelihood’ is a heuristic which helps qualify the immediacy of the risk. Using more than one person to discuss and rate the likelihood helps to minimise some biases and serves to make it a more considered and realistic rating. ‘Impact’ is a second heuristic that helps to qualify the severity of the risk and it should be determined in a similar fashion.

Finally ‘Mitigations’ should be a list of possible solutions to reduce the impact of the risk. The activity of determining mitigations should be performed by a team and take the form of a discussion. To determine the amount of time spent looking for mitigations, use the likelihood and risk to prioritise. Don’t think you need to have just one mitigation strategy – for a high impact risk, there may be a list. An example list of mitigations to our risk could look like this:

– Perform research activity this sprint to better understand the problem and improve estimation
– Begin integration activity as first activity in the sprint so we see if the estimates are wrong early
– Find engineer who has integrated Tensorflow into production environment to assist

Making a risk register once may be helpful, but it’s kind of like making a sandcastle – it will be quickly eroded by an ocean of changes and emerging new risks. Teams need to make a ritual of talking about risks and sustain the habit of tracking those risks. I cannot understate the importance of maintaining the routine of creating and maintaining a risk register.


You might also like The Dealmaker’s Guide To Tech Risk
Four questions that reveal insights into any software business that mitigate your risk.

Lack of visibility speaks to the old adage ‘if you can measure it, you can manage it’ – focus on the most important data to show how team track against their most pressing challenge. Burn down charts, uptime charts, active users are some of the scoreboards that can keep teams focused on the most important measurements that highlight risks. Once the team have established their risk assessment, having a scoreboard that helps them know how immediate those risks are is vital. To use our previous example, if we don’t understand what our deadline is or how close we are to it, how can I know what the impact is of my poor estimation? You need to find simple ways of keeping the most important metrics in the line of sight of the team to make the risk register actionable. And example of this is the development team that had 60 inch displays in their office with a site speed dashboard looking beautiful – yet they had no idea if their development work was on schedule. Delivery was always late. Wrong measurement for that team if they assessed their risk was on-time delivery. Right?

Finally, you need to have the individuals on the team owning the risks – and the team as a whole owning the assessment of risk. Understanding risk is everyone’s job is a critical step. Without this sense of ownership, risks will still be ignored. If you want to dive deep on ‘ownership’, I highly recommend reading Extreme Ownership by Jocko Willink and Leif Babin. The bottom line, everyone in the tean owns risk and everyone looks out for each other – but to do this effectively, they need the process of assessing risk and the indicators to show them when they should be putting their plans into action.

If you’re interested in adopting the use of a ‘risk register’ into your agile projects, try to incorporate it into your existing rituals. For example, a great place to leverage the risk register is in the ‘sprint planning’ session which would occur prior to the start of every sprint. This is the moment in time the team are thinking about what needs to be done and how they are going to do it. To make life easier for you, I have attached a download to this post with a template risk register.

DOWNLOAD RISK TEMPLATE HERE


You might also like The Dealmaker’s Guide To Tech Risk
Four questions that reveal insights into any software business that mitigate your risk.

thinking.studio

Level 25, 88 Phillip Street
Sydney
NSW 2000
Australia

+61 2 8024 5975
info@thinking.studio

©2003-2018 Pixolut Pty Ltd trading as Thinking.Studio
All Rights Reserved