Is it a dev? Is it a tester? No… it’s a quality coach.

Quality coaching is nearing two years old at Redgate, and the role looks somewhat different now than when it started. Originally, the expectations were that the quality coach role would be a pull-service, i.e. one that teams would request to help the team through a problem or determine an approach to a testing issue. The Quality Coaches would be ‘on standby’ waiting for the call, then swoop in — impart their wisdom, flex their testing muscles (wrong?), and fly back out again having saved the day.

This didn’t happen.

The cries for help didn’t come.

The development teams didn’t (for the most part) want help, they were content sorting out the issues by themselves. In fact some teams were in denial of any issues, blaming any drop in quality or released bugs on the fact they didn’t have any testers anymore.

There was a perception that it was the teams that were just not engaged with the quality coach role, and for the most part this was correct, but we think it was also the way the quality coach role had been approached.

Unwittingly, the quality coaches had adopted a ‘Superman’ persona, ready willing and able to fly in to help the helpless, to right the wrongs and save the day. It was a reactive role, dealing with existing issues identified by the teams. This was certainly not intentional but perhaps a result of how the role was perceived by the development teams, and no amount of marketing or explanation of the role could change that.

The coaches decided to change tack and try something different. They embedded onto teams, rather than observing from afar. Being closer to the teams, working with them, helped to build a trust relationship over time and allow the quality coach to do coaching, observe the real issues and work with the team to resolve them.

This approach meant the coaches adopted more of a Batman persona. No longer were they expected to fly in and save the day, but now they lived in the shadows of the team, watching, observing and using their skills (not superpowers) to identify and tackle root causes of issues. I’d love to say that they also learnt how to say “I’m Batman” in a gravelly voice, but I’d be lying! The role became more proactive, working with the teams earlier to head quality issues off at the pass, before they became issues. Being that person who asks the difficult questions and helps to ensure any code is written to be testable and tested.

This approach is proving to be the most effective one so far, certainly not without its problems (scaling being one of them) but is helping to build trust and overall level-up quality within that team.

In summary, our quality coach role is:

· Less about testing, more about helping with all aspects of ‘quality’ stemming right back to team basics/dynamics.

· Less about being the expert-in-the-room, more about being an impartial observer who sits outside of the team & product management who can observe, identify and analyse problems, areas for improvement

· Less about problem solving, more about coaching/working with the tech lead/team to resolve the problem

We are Batman!