Building a QA team - Part 2
Updated: Jul 13, 2020
Introduction
In the first part here, I defined the problem to be solved, clarified what I mean by a team and identified the characteristics of individuals I look for in forming a QA team. I also identified the characteristics of what I consider to be a good team lead. In this part I'll outline how I set the conditions for success. This is neither an isolated, nor dogmatic approach. Involve people, solicit opinions, act on feedback. 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 of what I've discussed and a primer for the next post
Part 2:
The process of building the team
The values I would want to embed
Inclusivity, Diversity, Openness and Accountability
A conclusion of 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 of what I've discussed
An overview of the process as a whole
Teams don’t just ‘happen’
The Process
So you've been through the hiring process or you've had an initial informal chat with existing team members. You now have a collection of talented individuals that reflect the diverse nature of your user-base at your disposal.
Time to turn them into a team.
“Teams don’t just ‘happen’ They are a result of a structured approach that mainly consists of engendering mutual respect, inclusivity, listening and reacting to what is in front of you.”
I’ve categorised the areas of particular focus into:
Setting the stage
Continuous development
Setting the stage
In setting the stage I like to begin to get to know the team, the organisation and vice versa. The end goal is a standard baseline for the team to adopt and move forward from. This will include inclusivity, openness and accountability. If you are inheriting an existing function it’s a great opportunity to determine existing attitudes. If the team you inherit are perceived as under-performing or problematic it’s a chance to analyse attitudes outside of the team. There may be a lot to unpick so a cautious, moderating approach is usually required. Be patient, people react differently to change, learn to read people and tailor the approach accordingly.
Continuous development
In Part 3 I’ll discuss continuous development comprising learning, BAU (Business as usual) and socialisation. It’s all about incremental improvements whilst maintaining the initial baseline. By this stage the team should feel comfortable in expressing opinions with each other and with you. The organisation should by now, have an idea of the process and should be aware of the rationale behind the process.
If it works for you and the team then that’s the correct approach
Don’t be afraid of mixing and matching elements. If it works for you and the team then that’s the correct approach.
Inclusivity
Create an environment where ideas (both good and bad) can be shared without fear of outright rejection, retribution or ridicule
Creating a psychologically safe environment
This is the single most important action that can be taken in the creation of a well-rounded QA team.
This is not promoted nearly enough in a lot of workspaces.
The workplace comprises a variety of personality types, races, genders, creeds, sexual orientation and other factors. This means that there will be various bias, both unconscious and overt, on display. The recruitment process and existing HR policies will ensure that an initial layer of filtering the more extreme biases. The job here is not to replicate existing policies but to create an environment where ideas (both good and bad) can be shared without fear of outright rejection, retribution or ridicule.
Providing a safe environment does not mean steering away from challenging topics but it will provide a support structure to ensure people are comfortable with feeling uncomfortable.
A simple method of creating the required psychological safety is to facilitate the creation of a document similar to an agile team's definition of a 'working agreement'. This allows differing perspectives to be captured and provides a source of reference for subsequent interactions within the QA team. The beauty of this is that the team are the ones who own the contents. The team has to interact with each other, articulate an argument, absorb different perspectives, share ideas, and collaborate to achieve the goal. Your job in facilitating the initial creation of this covenant is to ensure that everyone's voice is represented in achieving a consensus. This definition should be regularly reviewed by the team to ensure it reflects their current thinking. It is an ever evolving document.
Promote inclusivity
Ensure that historically under-represented sections of society have a place in the team. Actively listen to those people. Learn from their experiences. Teams thrive when individual experiences are represented. This will have a marked effect on the approach to the QA effort.
Diversity
We live in a multi-cultural society. The consumers of our software differ in ethnicity, gender and physical ability. Our QA teams should reflect this. An important factor in the role of a QA is to understand, to attempt to place our minds and our experiences within the context of our anticipated user base. We can do this long before personas are created, long before UAT, long before the model office, long before customer feedback, long before a line of code is committed. Diversity in a team means diversity of thought. Think about, and look beyond, the normal channels when recruiting and shaping the team.
Openness
I will miss things, don't be reluctant to point this out
Acknowledging mistakes
People are imperfect. People make mistakes. You make mistakes. Overtly communicating an acceptance of mistakes will go a long way in creating a psychological sense of well-being.
I like to repeat this simple statement “I will miss things, don't be reluctant to point this out” This is not a throwaway attitude to adopt, one sure-fire way to destroy trust from the team members is to cut-and-run when mistakes cost a release or a critical defect makes it through to production. The priority here is to learn from each and every mistake.
Accessibility
Everyone has worked for a lead or manager that promote an open door policy. However, when push comes to shove, this policy turns out to be vapourware. Don't be that person. If a team member approaches you it is your responsibility to give that person the time and attention they deserve. Get involved with the day-to-day activities of the team. If you find that your schedule makes it increasingly difficult to interact with the team, it is up to you to re-examine your schedule, modifying if required. Your team are more likely to listen to you if your open-door policy is a real, actionable policy and not a vapourware.
Awareness of bias
It's important that you are consciously aware of how you react to people and situations.
For example, you may have previously had negative interactions with strong personalities so any time you converse with someone with a strong personality you immediately default to the 'other' you. It is incumbent on you to be aware of this and modify your behaviour accordingly.
Open communication
Promoting open communication to your team serves several purposes. It radiates a sense of psychological confidence. It promotes dialogue. It allows you to maintain an overview of what is actually happening within the team as team members are more likely to
“Work smarter, not harder”
Accountability
Outline the responsibilities you have to the team
As the lead, it's vitally important to understand and communicate your responsibilities to the team. This is separate from the teams responsibilities to each other. The goal is to create an informal contract between yourself and the team that you can be held accountable for.
Respect accountability
Whilst you are open and you acknowledge fallibility, this does not mean that the team should adopt a wild-west attitude to development. It's important to emphasise that whilst achievements will be celebrated, transgressions will be subject to a fair and impartial review.
Note: the team covenant will help in reinforcing this.
Adherence to standards
Set baseline standards with the team, but be open to change. Explain that you will fail at times but you will hold yourself accountable. They aren't set in stone but you will do your utmost to respect and modify them if they prove to be unworkable or unattainable.
Accountability to stakeholders
It is important to assure the team that part of your role is to act as a buffer between the business and themselves. This may entail uncomfortable conversations with stakeholders that want more than the team can give but it is a necessity. Acting as the point of contact will reduce distractions for the team and will provide an amount of psychological security. It’s a given that you won’t win all the battles. If your team see you living this, it will implicitly engender respect that will filter into their day-to-day work.
Define roles and responsibilities
It is important to articulate or otherwise clarify the roles you have defined for the team. How you communicate these roles will be partly defined by your organisation's expectations and your expectations.
A team of technical rock-stars who can code like a developer and are vastly experienced in the tool-set in use (at the time) sounds exciting but the reality is very different. Each person will have strengths and weaknesses. What you’re attempting to achieve is balance. Coding skills can be taught, either by the developers or via courses. It is much harder to teach the essential soft skills. It is analogous to building a castle on sand.
Ideally, the definitions will be clear and concise. The definitions can include as much detail as you wish. Be aware that you must give the team the opportunity to question or ask for more detail. This will naturally lead on to goal setting.
Objectives and Key Results (OKRs)
Once the roles and responsibilities have been established goals can be set. A lot of companies use OKRs to establish goals and success metrics. They can be set at an organisational, team and personal level. OKRs typically work within a medium to large size organisation. A manageable number of OKRs for a team is around 3. Allow a number of sessions to set these and gain feedback from the team at each stage. If you use OKRs for the team there should already be OKRs for the organisation. At least one of the team OKRs should tie into one of the organisations OKRs.
This may be something as simple as 'Increase the visibility of QA across the organisation' which ties into an organisational OKR of 'Decrease the number of defects in production by 10%'. There should normally be around 3 Key Results per objective. The key results must be objective, measurable and advance the completion of the objective. For the example provided, a result might be 'Unit testing increased by 20% across teams'. This result is measurable and evidence can be obtained via a simple report.
It is important to allow the team the opportunity to articulate their own OKRs. Setting ambitious goals can enhance the team's engagement whilst achieving the goals and also promote collaboration. It's important to stress that OKRs are designed to be ambitious and missing the OKR is not an indicator of poor performance, it is an opportunity to gather data to inform the next set of OKRs.
The same process can be followed for individual OKRs. At least one of the individual OKRs must tie into at least one of the team's OKRs. Individual OKRs are ideal for upskilling the personnel and can provide tangible benefits across the team.
Articulate the servant / leader philosophy
It’s important to communicate this concept to the team. The focus here is that you serve the needs of the team, not the other way around. Care must be taken in articulating this, as done incorrectly it can seem like pandering. Lip-service to your well-intentioned initiative will be the result. It should not be used to avoid unpopular decisions or used as a crutch to avoid negative critiques of the team or individuals.
Gain buy-in from stakeholders
Once the team has agreed the OKRs they can be communicated to stakeholders. They are published internally and should be accessible from anywhere in the organisation. Everyone in the organization can see what others are working on. Regular reviews of the progress of the OKRs should be held. It can be useful to break down the teams OKR into manageable phases. This breakdown is not publicly visible as it is only used for internal tracking.
This is about the team, not the organisation
Establish regular feedback sessions for the team
As the team members operate in individual agile teams, this allows members a centralised setting to discuss their work, ideas, successes, problems, failures etc.
Set up a community of practice. Nominate one person to take notes with a view to publishing them after the session for internal visibility. Rotate this person for each session. They are responsible for publishing an agenda based on the output of previous sessions. Any topics to be discussed should be communicated to this scribe in advance of the session. Ensure that 'dead time' is allocated at the end of the session. It is inevitable that certain topics will require further discussion. There may be sensitive topics that the team would prefer to not be recorded. This is fine. This is about the team, not the organisation.
Establish regular feedback sessions for individuals
Set regular 1:1's for each team member. Get in the habit of making notes of each session, following up with an email to the individual only. It allows there to be a historical trail of what was discussed, actions taken and topics for the next session. Make them informal. An occasional off-site visit to a coffee shop can change the dynamic. Don't judge. Allow the individual to express themselves. The good stuff is nice but you should be more curious about what isn't going so well. Be on time, your time is not more important than the team members. Prepare for the 1:1 by reviewing past sessions.
“Focus on problem prevention rather than self-protection”
Vulnerability is not an indicator of poor performance
It's okay to say 'I don't know'. It is also okay to admit mistakes. It is okay to ask for help. Being vulnerable is not a natural state of being to most people and requires a certain amount of courage and trust in the process. Allowing people to admit vulnerability means that they free themselves to focus on problem prevention rather than self-protection.
Outline the team’s responsibilities to you, and each other
Outline the importance of the team interactions with each other. The object here is to create respect between team members. Trust will follow. These should be created and defined by the team.
Conclusion
In this part I defined the process, explained the mechanism behind the process and examined the individual methods that combine to deliver a high performing team. These are my recommendations, your experience may differ. That’s okay.
Here's two further experiments, again, they'll require introspection and honesty:
If you're a QA:
How many of those methods has your current team employed?
Which methods would you like to see adopted?
Do they spend the majority of their time in meetings?
If you think there are some that would benefit your team (in your opinion), be nice, provide feedback
If you're a QA lead:
Which of those methods have you attempted to adopt? What was the result?
Are there any methods you could retrospectively employ?
If you haven’t adopted any, why not?
If you attempt these, what’s the worst that could happen?
Do you spend the majority of your time in meetings with no outcomes? How do you communicate these to the team?
In Part 3 I'll cover methods I’ve successfully used in maintaining and motivating the team.
You can follow me on twitter where I post presumed nuggets of learned QA wisdom.