As software professionals, we know that every project has risk. It's a factor in every decision we make and every line of code that we write or evaluate. But are we truly prepared as teams to evaluate risk and act on what we find?
It's easy to say that you've thought about risk, but you need to formally evaluate it to be able to truly say that you've considered it much as you estimate story points or refine your backlogs. By thoughtfully and formally considering risk, you can set yourself up for a stronger sprint and a stronger team.
One question that is regularly raised is how to start to make a practice of formally assessing risk—of running risk assessment sessions. Here are three steps to introduce your team to doing risk assessments and processing the outcomes, to evaluate risk, and, finally, to work toward a plan to address it.
Introduce risk as a concept
The first step is to start introducing risk to your team. You want to make sure that you're aligned on what risk is and the impact it could have on your team's decisions. The definition of risk I find most useful is that risk is the impact of failure and the probability that this failure will occur.
You want to be sure that your team is following the same definition of risk across all members. This one works wonderfully because it's fairly simple and it's easy to add layers to it as your team needs.
This can take a few different forms, depending on your team. Your team will have a baseline understanding of risk and how it applies to software projects. This understanding might be perfectly aligned, or it could be vague enough that it's not very useful.
First and foremost, you want to become aligned on what risk means. The best way to do this is to ask!
Start communicating
With a team that has a culture of openness and a questioning nature, you can often start this in your team's preferred communication tool. This could be Slack, Teams, Hangouts, or anything else.
Start a thread or discussion by asking, "How do you define risk?" or, "What do you think is most risky on our project?" This lets people have a place to express themselves and gives you a good feel for how your team understands and operates.
If your team has a refinement session, this is a great place to bring up risk. I've found great success with suggesting that a particular story is risky and explaining why. This takes a little preparation; you'll want to have become familiar with the stories in advance and have already done an informal risk assessment on them.
This means you'll want to have given thought to what the failure conditions are and what the likelihood of these failures occurring are—before you arrive at the refinement session. This lets you work on your own definition of risk and become a subject-matter expert, and it can better prepare you for the formal risk assessment session.
You may be called upon to justify why you think a formal risk assessment session is worth the team's time. People tend to suffer from "too many meetings" syndrome and may revolt at the thought of yet another one. Here is where you will need to call on your powers of persuasion!
What makes risk assessment worthwhile?
We have a general feeling about risk through our time as software engineers, testers, and other members of the software development team. But as with anything else, if we don't calibrate and discuss those gut feelings, they slip out of sync and out of balance. Resetting our concept of risk helps us communicate more efficiently as a team and get a better idea of our project—something we all can use!
If your team uses points and pointing, you can start your justification by using that. If it does not, then any form of estimation works. You need to estimate the amount of work involved in a ticket to be able to add it to your workload. In a similar vein, you need to have a good picture of the estimated risk involved before you can reasonably move forward with a task.
You can also think of it like workers on a roof: They know it's risky to be up there, but they've considered the risk of the activity and weighed it against the gain. Then they take reasonable precautions for the risks they have assumed. As software professionals, we should do the same.
Decide how to evaluate risk
Once your team is onboard, you'll want to evaluate the risk of the specific items in question. You can do a full risk assessment, an informal session where you think about it yourself, or ignore it entirely.
Obviously, I don’t recommend the third route.
I do recommend thinking about whether there's a place for a full risk assessment on your team. If you have the buy-in for it and can run a session as described, then you're going to have a more cohesive team that's well set up for the challenges of the software development lifecycle.
That being said, even an informal session that is publicized to your team can do a lot of good. They'll understand how you see risk and how they can start thinking about it themselves. And, of course, if they disagree, that will create the opportunity to talk about a full-team or partial-team risk assessment meeting.
Make a plan for risk
Once you've gotten an idea of the risk of the items you're looking at, then what? It's not much good to have a page of numbers that you never look at again.
After you've looked at risk, evaluated it, and come to an agreement with your team, you want to start acting on the identified risks. This can take several forms, depending on how you're using and identifying risk.
If you're in a refinement session, risk can be used to determine which stories you want to play in a sprint. It can also help determine, over a long enough time line, how much risk your team can tolerate in a sprint or given body of work. As you continue to evaluate risk with your team, these evaluations will only get stronger.
Another use for risk assessments is to surface risks you weren't aware of before and those that you want to have a particular plan in place to deal with. On my teams, this generally means describing the risk and then talking about a mitigation plan.
One example of a risk plan
On a team that I recently led, the application needed to be very trustworthy. The risk we identified was that if our users did not trust the application, they wouldn't use it—which would put our client in a very difficult position. We identified three mitigation strategies for this:
- Be cautious not to give users any reason to distrust the app.
- Be sure to give the app a strong, consistent voice.
- Be careful about small defects slipping through.
Keeping these three things in mind would ensure that we delivered an app that met our client's expectations.
Get better at making software
Taking these steps to introduce risk to your team, evaluating it, then making a plan to mitigate it will help create a better team dynamic and a better end product.
You can train yourselves to thoughtfully consider risk over a sprint or the lifetime of a product, which will make everyone better at all steps involved in creating software.
Join Jenny at the STAREAST Virtual+ conference session, where she'll be speaking on "Running Risk Assessment Sessions," "Building Automation Engineers From Scratch," and "Making and Managing Mind Maps." The conference runs from October 5-8.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
