Quality Coaching: Focusing on Frictionless

TL;DR It takes effort to persuade by logic or motivate people. You may achieve more success by removing team obstacles that are preventing them from performing quality-related tasks.

In his book "The Happiness Hypothesis", Jonathan Haidt created the rider and elephant metaphor to describe two sides of our minds, the rational (the rider) and the emotional side (the elephant) and the path we wish to follow. He uses it to describe how our emotional side often influences us more than our logic when going down a path. Dan and Chip Heath used this metaphor in their book Switch, suggesting that shaping the path, may be a more effective way of influencing change.

The Rider and the Elephant.

The inner game

Tim Gallwey, tennis coach and one of the original thinkers of modern coaching, describes how people have both an inner and outer game and while many focus on the outer game of being skilled at a craft (in our context, software engineering), he believes that the inner game is also crucial for success. He offers this formula to describe the inner game:

Performance = Potential - Interference

Where potential is an ability to master a skill, interference can be both internal or external and inhibits our ability to perform.

He advises the coach to focus on removing the interference, rather than aiming to improve their potential.

Improving Product Quality

When I think of quality coaching both these ideas resonate. When I first started out as a quality coach, my goal was to focus on improving people's performance. How could I help a software tester or a software developer improve their testing capability?

And while I had significant success, it was clear that motivation was integral to a successful outcome.

It got me thinking. What if I focused on interference instead of focusing on the potential? Why don't I focus on shaping the path, instead of trying to motivate the elephant?

External & Internal Interference

Tim Gallwey describes interference as both external and internal. Examples in the tennis world of external interference could be not having a tennis court, or not owning a racket. Internal interference is the self-talk that tells you 'you can't do serves', or 'your backhand is crap'.

It feels like external interference is similar to 'shaping the path' and internal interference like 'persuading the elephant'.

As quality coaches, we must deal with internal and external interferences. We have to 'shape the path' and 'influence motivation'.

Shaping the Path

Shaping the path is way easier than persuading anyone (let alone an elephant) to modify behaviour. In situations of low motivation and low trust (and low trust could be simply you are new to a team), it makes sense to focus on external factors such as:

• Test Environments
  This is such a practical thing you can do. Focus on either creating and/or maintaining test environments.
• Infrastructure
  Pipelines, frameworks, release processes, testing in prod. All these are critical elements of modern software development. Think about building templates into repo's allowing for rapid adoption and rollout.
• Test Data
  There are many types of test data out there. Seed data for test automation, masked and obfuscated production data, and a blend of both. Having diverse test data is important for any team's confidence level.
• Story Sizing
  If there is one thing I would ask teams to do to improve quality is to 1) slice stories by domain 2) scope a story from 'pixel to persistence and 3) deliver the smallest possible value. Work with your delivery lead to get this going. It will be painful at first, but the wins of this approach to improving quality and building confidence will have your team thanking you.

In any of the above ways, a quality coach can remove friction in a team's delivery process and deliver value to customers. You can even measure reduced unplanned work to demonstrate improvement.

You don't have to stop there. Just because an elephant is large, doesn't mean you can't persuade them a little to change their mind.

Persuading the elephant

It is difficult to persuade and motivate a team to invest in software testing for many reasons;

• Confidence: Fun fact. Most universities offer minimal training on testing; if they do, it's on unit testing. Joining the real world and discovering testing is 'part of the work' requires learning new skills. Lack of confidence in testing ability can play a big part in why teams don't test.
  
  Suggestion: Arrange organised training programs in both test automation and exploratory testing. Confidence will build in time as the team gets more practised.
• Status: "Testing is below my pay grade". As much as I wish testing was not undervalued, the stark reality is that in many organisations you will find people who perceive software testing as a task anyone can do. If you are lucky to work in these places where software testing is valued, you will find these people marginalised.
  
  Suggestion: My approach here is to focus on individuals in the team who support software testing and use them to try and influence the rest.
• Fear of Failure: This one is a powerful one. I've seen teams reluctant to release in case a bug is released to production.
  
  Suggestion: Encouraging monitoring and the ability to recover quickly can help reduce this feeling.
• Overwhelmed: Many teams feel pressured to release features and do not " have time to test". This is not a fun place to be in. Planning time ahead of development is required to understand and estimate.
  
  The key is to work with product owners, and delivery leads to ensure time is included from the start in a real and tangible way. Insist on this. Make this one of your red lines. Get cards on the backlog.
• Uninspired: I LOVE TESTING, but I know many people don't enjoy it and find it boring
  
  Suggestion: As a quality coach, you can aim to make testing fun, doing bug bashes and exploratory testing.

Shape the path, then work on the elephant

Focusing on external factors such as building test environments, supporting tests in production, and making it safe for the team to 'fail' are good places to begin in quality coaching. This is particularly true if you are new to a team or company and want to build trust. Focus on low-hanging fruit. That is an opportunity where you can quickly demonstrate a win. A tangible success that comes quickly offers confidence in you as a quality coach.

Now work on the elephant

Play the long game with internal factors. Internal factors can take months to impact a team. Building trust and relationships is critical. Don't forget that context is critical here. Any factors below may be reasons to lower expectations in: yourself, the team and senior leadership about what success will look like for three months, six months and 12 months.

• the criticality of what they're working on,
• their software engineering experience
• the familiarity with platform technology including testing frameworks
• the experience in software testing
• time allocated for experimentation and exploration
• the psychological safety offered to you

When putting together a plan, I suggest you include short-term wins and long-term plays to impact both internal and external interference.

As always, the key is to have a toolkit of many tactics and approaches. And be prepared for change. It will come, just the shape will be uncertain. Have a plan, but be ready to tweak and pivot as the team shifts and changes.

What are your experiences in influencing both internal and external factors?

thanks to Anne Colder for telling me about the Elephant and Rider and Rob Meaney for his phrase - pixel to persistence.

Ask the Book

Welcome! Ask anything from the Handbook.

How can I start improving quality without slowing delivery? What should I focus on first as an engineering leader? How do I coach teams toward better systems thinking?