Teachable moments in Quality Coaching

Intro

I'm Gerard McCann. I live and work in Belfast, Northern Ireland, as a Software Development Engineer in Test (SDET) for a smallish (100-person) organisation. There are always opportunities to improve quality based on past and current experience by identifying and seizing teachable moments. The article shows how quality coaching based on teachable moments may be approached and can help the team's efficiency and effectiveness.

Quality Coaching

As a reminder, per Anne-Marie's article, What is a Quality Coach, a "quality coach guides, supports and rallies a team to collectively own and improve quality through facilitation, education, experimentation and visualisation. They are a passionate advocate for quality."

Teachable moments

The term teachable moment comes from education. Wikipedia says it "is the time at which learning a particular topic or idea becomes possible or easiest." Unfortunately, it's not always possible to undertake proactive quality coaching, which can mean we have to quality coach more reactively. I identify and seize teachable moments most frequently when a gap exists between the team's expected and actual performance, e.g. something has maybe not worked out in a sprint. As a quality coach, I'm jumping in quickly to help the team with the following steps and prevention from a quality perspective. The article explains the how and what around this.

Winning hearts and minds

To win hearts and minds, a sterling piece of general coaching advice is: "ask before you tell", which I think relates to the IT concept of not calling someone's baby ugly. A practical approach for this is clean language, which is from psychology and offers a simple set of questions to direct a person's attention and help them figure out the best way forward. Doing this helps ensure the quality coach remains neutral (i.e. nobody's baby gets called ugly) but also helps the team establish and explore the root cause and generate potential solutions.

Don't confuse speed with progress

Einstein said if he had 60 minutes to save the world, he'd spend 55 minutes thinking about the problem and 5 minutes coming up with a solution. That's around 90% thinking time to 10% doing time. For me, that begs the question of what a good ratio of thinking to doing should be for a given situation. For example, suppose the team seems to be speeding ahead but progressing slowly due to lower quality and more bugs. In that case, there's a teachable moment around the thinking-solution ratio we've adopted, and quality coaching can help the team establish what we can do differently.

Show, don't tell

A super simple but very effective quality coaching tip coming from many teachable moments is to ask if we can show, not tell. So I ask folks how we can get on the same page, possibly using a screen share to display a web page, a Miro board or a User Story rather than talking more abstractly. When we see the same thing, there's less possibility of misunderstandings and more effective and efficient progress.

Communications

Given the central role of communication in collaboration and things like bug reports, improving the team's communication is my key quality coaching goal. If we aren't communicating optimally, getting a message across takes much longer, and the point may get missed. A book I've used for communications in quality coaching is the First Minute by Chris Fenning.

The book explains the root causes of poor communication and how three things should be given in the first minute: context, intent and critical message. This way, the receiver isn't left asking, "what does this relate to?" (no context), "why am I involved in this communication?" (no intent) or "is there something you need me to help with?" (no key message).

An example of how communications improved based on the book: I'm working on the XYZ feature scheduled for Friday's release (context). I found a significant issue affecting your test automation (intent). Please give me 10 minutes for a show and tell (key message).

Times where I identify  teachable moments:

• Mob programming - I've found this helpful in proactive and reactive quality coaching. Understanding how developers think and read things like acceptance criteria versus how QA/SDET do these things is also beneficial. Where there is a difference in thinking, there's a golden opportunity to do quality coaching to help the team improve.
• Code reviews - These typically offer more of a passive opportunity for quality coaching when we leave comments in a pull request, for example, on how we think a user control may be used differently from how it has been written. However, we sometimes undertake dynamic code reviews/walkthroughs, which afford more active opportunities to take quality coaching to a higher level.
• Bug triage - These are great for quality coaching on areas like bug validity, bug title/description, replication steps and any other bug information that has (or has not) been given. Bug prioritisation is excellent to ensure alignment between the various stakeholders we ask to attend and for us to discuss and check in on specifics around the meaning of quality as value to some person (at some time)
• Agile ceremonies - Engineering review is a crucial ceremony where we perform quality coaching to help shape User Stories, improve acceptance criteria and get testability baked in. Retrospectives are another significant ceremony where the team gets to identify opportunities for improvement, and I pick up on areas where quality coaching can be done moving forward.
• Escaped bugs - In Lessons Learned in Software Testing, the authors encourage us to consider how bugs escaped and if these are natural consequences of the approach taken to quality. Root cause analyses done on escaped bugs take time and resources, but we undertake them selectively, given that they provide the team with many opportunities for quality coaching.

Some quality coaching phrases and ideas I use:

• What do you/we want [to be different]? This is a deceptively simple phrase (stated with or without the words to be different). However, depending on which word we emphasise, it has an entirely different meaning. For example: "what do we want?" versus "what do we want?". The first variation is getting at the distinction between knowing what we do and don't want, which can sometimes help focus the team on finding solutions rather than dwelling on the problems, and the second helps get focus on what the team wants rather than what someone else wants. There is another variation where we swap the word 'want' for 'need', the two subtly, yet sometimes notably, different.
• What can we do? This is about creating a basis for action, thinking of moving forward and choosing one of several options. It also helps shift focus from things we can't do, as these can keep us rooted in the spot.
• What's the problem we're trying to solve? I use this question whenever a discussion seems like it's going down a rabbit hole or if we are getting bogged in implementation details without fully considering the bigger picture.
• Would the roof cave in if we stopped doing this work altogether? This is a question from a quote by Peter Drucker, which goes well with another of his quotes: "There is nothing so useless as doing efficiently that which should not be done at all." This is a great question I ask during quality coaching to help us ensure we do the right things and thus avoid waste.

Conclusion

Teachable moments provide us with situational quality coaching opportunities through which we help guide, support and rally the team to improve quality.