Back to the blog

Addressing Risk with Lessons from CAST 2018

Picture of Lisa Crispin
byLisa Crispin

In my previous post inspired by the CAST 2018 conference, I described some ways testers and other team members can help their delivery team manage risk and respond to uncertainty. There were several sessions at CAST that helped me add more risk-mitigating tools to my toolbox.


Because you can’t test everything…


Jenny Bramble helped us build a common language that lets us talk about risk. We never have time to test All the Things, so we need to figure out where to focus our testing, and communicate that to stakeholders. So often, we use the same words to mean different things. We need to define terms that let us communicate across our delivery teams.


Jenny uses the tried-and-true risk matrix: rate the impact of a failure, and the probability that the failure will occur. Multiply those together to help you prioritize where to focus. What’s fragile in the code? Are there external changes that could impact it? Risks can be related to time, environment, natural disasters, hiring new team members. Use risk analysis to evaluate whether our assumptions are correct. Ask questions.


Are you proud of the feature you just delivered? Jenny pointed out that this should be part of our “definition of done” - morale matters, though it is hard to measure.Tweet ThisTeam members need to feel safe to point out risks and share information. We can use the outcomes of risk assessment to educate product owners and stakeholders about why we are testing what we test.


Getting the right people


Back in 1999, Alistair Cockburn published a study “ Characterizing People as Non-Linear, First-Order Components in Software Development”. He found that the key to successful product delivery is to get the right people and get out of their way. But who are the right people, and how do we find them? I was in two eye-opening sessions at CAST that challenged my personal biases about recruiting and hiring.


In her session “Recruiting for Potential”, Lena Pejgan Wiberg revealed she had based hiring decisions on gut feel. Pretty resumés got attention, poor ones did not, resulting in low diversity. Lena mentioned several biases that impede our hiring, such as confirmation bias, halo effect and overconfidence bias. What’s important in a person’s ability to excel at testing? She found that giving candidates a “homework” project, like how to test an input form, wasn’t helpful. She really wanted to know how the candidate analyzes, tests, plans, executes, reflects, tells a story, has courage.


Lena warned us of the danger of thinking you’re open-minded. You aren’t. Respect each candidate’s time. If you take part or all of someone’s day, you should pay them for it. I’ve been paid for a four day interview process. I did some workshops and consulting as well as participating in more traditional interview meetings. Paying me for my time meant everyone got value and it didn’t matter if we decided not to join forces.


It’s so helpful to me to learn how unconscious biases affect just about everything we do. It’s hard to overcome biases we aren’t aware of, but we can take steps to make sure we evaluate candidates fairly.


Neurodiversity in teams


I’ve been learning about neurodiversity from Sal Freudenberg and others. Even so,  Mike Tozer’s session on “Highs and Lows of Managing a Neurodiverse Testing Team” was surprising and revealing. His company hires people on the autism spectrum who are highly effective testers. These people are bad at interviewing. They can be quite literal, and their social skills may be lacking. But there 125 million people with autism worldwide. Their autism gives them many advantages as testers:

  • Superior concentration
  • Exceptionally creative thinking
  • Frank questioning
  • Incredible attention to detail
  • High integrity

They are, in fact, so focused on their studies they don’t get out to career fairs and look for jobs. At the same time, there’s a huge talent gap in areas such as cyber security. If we don’t change our hiring practices to set these people up to succeed, we’re missing a huge opportunity.


Mike gave an example of a person named Tim, whose autism meant that he was unable to travel on public transport. Mike’s company hired him and let him work remotely. Tim has no problem using Slack, and he’s an incredibly gifted video game tester.


Neurodiversity includes other conditions, such as ADHD and dyslexia. Mike explained how we can we make our hiring process inclusive of neurodiverse people. Make the interview environment like the work environment. Give clear directions for what you want the candidate to do. Minimize distractions. Use alternatives to psychometric testing. Don’t use eye contact as a measure of “trust” - many autists find eye contact physically painful. Hearing can be an issue too, they may be sensitive to certain sounds.


The basic guideline is to assess each candidate for the job they are going to do - not for their skills at being interviewed!  Set them up for success after hiring, too. The size of the team matters. They don’t need more management, only different management.


As with other diversity and inclusion efforts, what works well in hiring people on the autism spectrum also works better for everyone. These super-talented testers help make sure we catch the “unknown unknowns” and the problematic scenarios that no one else thinks to try.


It’s about people communicating and collaborating


Assembling a talented, diverse team and providing a psychologically safe environment where they can do their best work together is a superb way to identify and mitigate risks. We need tools to
automate the tedious, repetitive tasks so we have the time to use our human capabilities and do the value-adding activities that make our customers awesome. It’s exciting for me to be part of a team at mabl that is thinking of ways to use new technology to help build confidence in our software products as we deliver more and more frequently. What small experiments will your team try?

 

Automate with mabl

 

Back to the blog