Moving to a Quality Coach Role

I posted the following on Twitter...

The perspective in mind was a software tester transitioning to the role of quality coach. The responses though offered many different perspectives (the power of diversity)! By correlating these perspectives to stakeholders impacted by the transition, I was able to identify user stories.

I enjoy writing user stories with quality in mind. I find it clarifies the why a lot more, something we often forget to do when we think about quality.

Quality Professional

" As a software tester I want to ready the team so that I can perform the role of quality coach instead of doing the testing".

Some great suggestions were put forward in this space and I'll summarise:

• Perform a self-reflection (how ready am I for this transition, what do I know, what do I need to know) @StuC
• Encourage the team members to try the role of a software tester.@Lanooba
• Speak to the team on the transition and repeat the reflection at a team level (Follow up a week later to allow people additional time and space to reflect as this may be new territory for them and they won't have immediate answers). @Magnus
• Imagine you were going on holiday for six weeks, what information would the team need to do your job?

Delivery Lead

"As a delivery lead, I want to know when and when the team and the quality coach will interact, so that the team will know when and where to perform software testing"

When there's loads of uncertainty and no one quite knows where to start, focusing on the delivery process allows the team to have practical conversations about when and where software testing should be performed, and when and where a quality coach might check in with the team.

This won't uncover all that 'glue' work performed outside of the delivery process that a software tester typically does, and it doesn't help with improving software testing skills. It's the 'Shu' in the Shu Ha Ri of learning, and so makes it an excellent starting point.

Team members

"As a team member, I want to know what how to do software testing well so that I can confidently make decisions about what to test"

The more you create and do software testing, the more confident you become in your choices. Software Testers don't have a special magical skill that helps them find bugs, it's years of practice of experimentation. We have a hypothesis, we try out it, and if we're right, we find a bug, or we create a good test.  We already know that pairing is a powerful tool when transferring skills and so the suggestion by Joep Schuurkes got a big + from people.

Engineering Manager

"As an Engineering manager I want to understand the nature of the role so that I can assess if they're performing the role well, and can reward appropriately"

This is critical for senior management who need to be confident that the role is more than waving your hands around encouraging people to "do more testing". Mark Tomlinson explains it well:

Creating career pathways, creating role descriptions is important to ensure buy-in and that people are properly compensated for a role that requires leadership skills and nuance in its application.

Who drives the change?

A final stakeholder is required. Someone with the capability to speak to what success looks like has the comm skills to speak to people at all different levels of the organisation, has the power to influence and change.

I call this person the Head of Engineering, but it also could be an external consultant.

Nicola Lindgren touched on this.

They have a user story too.