Elevator Pitch
In agile, we think of risk at a low level. Timed right, requirements can be edited quickly and code fixed on the fly. DevOps has new bigger risks especially for those working on large scale releases. I will talk about my experience with older risk models in the new world.
Description
Let’s talk about risk
Risks have a bad reputation. Sometimes justly so. Some risks have grown up and turned into huge embarrassing issues for companies and massive inconvenience for their users. Other risks can be positive. These are the good ones worth taking that save time, money and effort.
The type of risks that delivery teams need to be able to assess are the negative ones with the bad consequences (implosion of product, team, reputation).
What is a risk?
A risk is something that has the potential to turn into an issue. In 20 years of working in delivery teams, I have concluded that there are 2 key concepts to understand about risks which are crucial to understand. Understanding of these concepts can sharpen how you assess risk and communicate severity.
This is a talk that will take you through what those concepts are. Understanding of them are the key to helping your team plan a suitable strategy for dealing with the concept of risk. It will also give them the confidence to work (or not) on individual risks before they become issues.
Risk analysis
All members of a delivery team must be sure to communicate if they see a risk or an issue when reporting to their feature team. However, this can be tricky if you are not used to thinking in a risk-focused way or have no appreciation for your own tolerance of risk. Over the years, I have worked out some tactics for dealing with this which I would like to share with you.
Risk face
Everyone has a risk face. It indicates when they have got to the point where they are so such an issue will happen that they are not willing to take the risk and they indicate this with a change of facial expression. I have a game I play on stage as part of this talk that reveals people’s risk face and helps people access for themselves what their own personal (in)tolerance to risk is. It’s a great way of getting engagement in the talk. Also enormous fun for those taking part as I urge people to partner up and watch the person beside them for signs of “risk face” as I get closer and closer to “breaking” something on the stage. (No cleaning up is necessary afterwards)
Risk analysis
Using an easy to understand example, I am going to illustrate a risk and how it goes from:
* very likely to turn into a massive issue
* perhaps likely to turn into an issue impacting a limited number of users
* not really important if it turns into an issue
Traditional risk analysis models
As part of this talk, I take a look at older risk profiling models and talk about their suitability in the new world of DevOps automation and agile. Are there lessons that can be learned from established ways of risk profiling or is it better to re-invent the profiling wheel? I came to a conclusion on this which I will share as a part of this talk.
Under the older delivery models (Waterfall, v-model) we were encouraged to write risk-based plans and approaches on the basis we could not test everything so we would just look at the risky area. POSITIONING CLARIFICATION: I AM NOT ADVOCATING A RETURN TO WATERFALL.
As an example of ONE of the recommendations I make as part of this talk - I advocate that testers apply the same shift left thinking that we apply to code and requirements to risks. Let’s get close to our risks, understand them and, where appropriate, advocate for their removal from a place of knowledge and understanding. This talk will show a new model for risk-based analysis proven out in multiple delivery teams.
Communicating risk
YOU MUST understand the root of the cause and the very end of the impact in order to be able to make the recommendation to remove or fix an issue.
“Feature missing”, “feature inaccessible” or “feature not working as per requirements” is not the end of an impact – it is just the beginning. As with the impact of my game above, had I gone to the most severe level of risk, there would have been multiple additional issues, knock on effects of x being broken.
Takeaways
When does a risk move from something that is acceptable to something that must be fixed?
How can we analyse the likelihood of a risk turning into an issue?
What’s the difference between mitigation and a workaround?
How can anyone in a delivery team drive part in the conversations to decide which is the better option?
How to expose risk at every stage of the software delivery process
Notes
Besides a screen and a microphone, I have no tech needs to deliver this talk above and beyond those of most speakers.
I am Irish, educated in Cork, living in London. For conferences outside of London, I will require that travel and accommodation are covered. As part of my travel, I will look up and offer to talk at local free events if the timelines work out.
I am 20 years in testing this year and still hands-on every day. I am the designer of the internal training framework for our London office competed in collaboration with the testing team I support in London. I also received a lot of great feedback and input from the Scott Logic grad class of 2018 and 2019. Risk modelling and communications are a huge part of that training.