Building a QA team - Part 1
Updated: Jul 13, 2020
“Building a team that communicates freely and openly towards a common goal in the pursuit of a quality deliverable will always outperform a collection of disparate individuals with their own agendas.”
Introduction
A team is the beating heart of any software development process. People develop software. Those people have differing roles. Those people have differing skill-sets, values, inherent biases, approaches and communication styles. The list is endless. As this is aimed at QA I'll concentrate on building a team to support the QA function. The role of a QA function is context driven. It is dependent on the wants and needs of the organisation. No two QA functions will be the same. Creating a diverse QA team with shared values will make it easier to promote that mindset and those values to the cross-functional teams that the QA’s are a part of.
I’ve worked within functions that have contained some of this approach. I’ve formed teams based on this approach. There is no downside to implementing this approach unless you view people as ‘resources’. That has never worked for me. I like to treat people as people with their own ideas, strengths and weaknesses.
In this 3-part series I’ll explain what I’ve experienced in the creation of a great team, I’ll also explain the methods I’ve used in building a team. I don't dive too deeply into the technical aspects of team members. Tool-sets, languages and basic technical concepts can be taught relatively quickly. They can also change dependent on the organisational expectations. Communication skills and attitudes can be coached over a period of time. I look for those qualities that are transferable regardless of the tech stack. I want to build teams that last, even when team members leave (as they will). There's a certain satisfaction in knowing that the attitudes and skills you've helped to embed will be replicated within other teams, at other organisations. Part 1:
The problem I’m trying to solve
What is a team?
The qualities I look for in team members
The qualities I aspire to live up to as a lead
A conclusion on what I've discussed and a primer for the next post
The process of building the team
The values I would want to embed
Inclusivity, Diversity, Openness and Accountability
A conclusion on what I've discussed and a primer for the next post
The ongoing development of the team
Learning, Business as usual and Socialisation
A conclusion on what I've discussed
An overview of the process as a whole
“A QA function advocates for the implementation of a quality mindset at each stage of the development lifecycle via coaching, mentoring, pairing, debate and hands-on effort”
The problem
Without identifying the problem to be solved how can you possibly start to derive a solution?
How do you build and lead a QA team that, by the very nature of the agile development approach, don’t work side-by-side with their fellow QAs through the working day?
The specific problem to be overcome is ensuring that the QA can work within the constraints of their cross-functional team and as part of a wider QA function. These two may have different priorities and different approaches. This series of posts doesn't attempt to solve the specific cross-functional team working paradigm but will focus on the creation of a shared values structure for a specific QA function. This shared values structure naturally leads to the evolution of a team. The added benefit of this approach is that the same characteristics can be applied within the cross-functional team in the pursuit of the whole team ownership of quality.
What is a team?
The first thing we need to do is understand what a team is? We can all point to successful teams. Football has Manchester United, Rugby has the All Blacks. The Red Arrows would be classed as an exceptional team.
Identifying what makes them successful? That's way more difficult. There are thousands of articles and studies that attempt to answer this. The majority of them contain valid points, the majority of them appear to address repeating themes. Context is everything. It will depend on what the expectations of the organisation are. It will depend on you and your approach.
"I had way too much information and interaction" is a statement repeated by no competent team lead ever.
My simple approach is "Building a team that communicates freely and openly towards a common goal in the pursuit of a quality deliverable will always outperform a collection of disparate individuals with their own agendas"
There are numerous definitions of the word "team".
team - noun
A number of people who act together as a group, either in a sport or in order to achieve something
team - verb
To act together, to achieve something
In this case, both the noun and the verb are relevant.
I’ve been responsible for these two scenarios:
There is an existing team you have to lead
You have to create a team from scratch
I concentrate on the people with the right characteristics first. I look for people who are eager to learn. I like people who are aware of their own, existing, limitations and are unafraid of improving these limitations. Knowledge of tool-sets isn't a factor.
Qualities I look for in a good QA
These are what I’ve looked for when considering team members, your experience and expectations will be different:
Independence of thought and action
An empathetic outlook
A challenging mindset
A diplomatic approach to conflict resolution
A collaborative nature
An innate curiosity
A supportive disposition
A willingness to be wrong
Technical aptitude
Personable
Bravery in the face of adversity
The presence of these qualities can be derived during the interview process or from an initial informal chat with existing team members. Structure either interaction so that the conversation flow covers these points via examples or scenarios. The skill here is to not converse in bullet points but in a relaxed exchange of ideas. The onus is on you, as the lead, to steer the discussion to obtain the information you need. I've seen, and faced, the interviewer offloading responsibility onto the interviewee. You know what you want, don't make the person jump through artificial hoops to make your job easier. Information obtained at these stages can then be used when formulating hiring decisions or personal plans. You may have people that are very diplomatic but aren't as strong when faced with push-back. That's okay. You may have people that are technically adept but are dogmatic in their approach. That's okay as well. No-one is perfectly formed from the outset.
Qualities I aspire to as a QA team lead
“Be the change you want to see”
When I’ve built a team, these are what I’ve aspired to:
Respectful of different opinions
An ability to listen
The willingness to the do the right thing, not the most expedient thing
An inclusive mindset
A servant / leader philosophy
A mentor / coach
Adept at communication, both written and verbal
An understanding of the necessity of standards
An in-depth knowledge of the QA role and the challenges encountered
An ability to communicate information at the appropriate level dependent on the level and person you’re communicating to
Sound like any leader profile you've ever read? These characteristics have stood the test of time. It is vitally important that you are aware of your own limitations in these areas as without this awareness you run the risk of becoming the very thing you dislike. Awareness means that you can develop an internal strategy to mitigate these weaknesses. These weaknesses don’t automatically disqualify you from being a champion for your team, they will ultimately drive you in becoming a better lead.
There’s a difference between team conversations and team decisions
There’s a difference between team conversations and team decisions. Part of your job, just like the day-to-day work as a QA, is to evaluate logical arguments and make decisions based on them. These decisions may not always be popular. That’s okay. It is also useful to be aware of team discussions devolving into talking shops. Part of your job is to facilitate these discussions and that means ensuring the ‘thing’ being discussed is the ‘thing’ being discussed.
Every organisation has someone who will ultimately make decisions. You may be expected to make decisions that affect the team. It's okay to gather information to help you make these decisions. Don't be pressured into making a snap decision based on incomplete information. Unless you control the relevant factors, the decision you make will be part of a bigger decision that you help inform. This isn't the military, you aren't building a bridge for refugees who are under fire.
It is possible to disassociate team building from knowledge of the domain. It’s very much harder to make a meaningful impact without an in-depth knowledge of the function you’re representing.
A large factor in the decisions you take are predicated on an ability to understand the implicit nuances that a QA faces on a daily basis.
It’s also important to understand that experience is no indicator of ability. I have my own, internal, issues with personnel being considered fit for a role because of time served in post or time in a particular role. If someone has spent 10 years in a particular role there’s no logical conclusion that leads to them being a good leader by default. It also doesn’t apply that they will have an in-depth knowledge of their function.
Conclusion
I defined the problem to be solved, clarified what I mean by a team and identified the characteristics of individuals I like in forming a QA team. I also identified the characteristics of what I consider to be a good QA team lead.
Here's two experiments you can try, they'll require introspection and honesty. If you're a QA:
How many of those qualities do you currently possess?
Which do you possess but need to improve on?
Which of those qualities does your current lead exhibit?
If they are missing qualities (in your opinion), be nice, provide constructive feedback
If you're a QA lead:
Which of those qualities do you exhibit?
Which of those qualities do you need to improve on?
Any of your engineers are potential leads, which of those qualities do you currently coach?
How could you coach those qualities in your day-to-day work?
In Part 2 I'll cover the process of forming the team, outlining the core values you would want to embed. I'll cover Inclusivity, Diversity, Openness and Accountability.
You can follow me on twitter where I post presumed nuggets of learned QA wisdom.