Building a QA Team — Part 2
Introduction
Introduction
In the first part of building a QA team 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 not an isolated nor dogmatic approach.
Involve people, solicit opinions, act on feedback.
Part 2:
The process of building the team.
The values I like to promote and embed.
The importance of Inclusivity, Diversity, Openness and Accountability.
A conclusion of what I’ve discussed and a primer for part 3.
Part 3 covers:
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’
High performing teams don’t just ‘happen’
The Process
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 (hopefully) reflect the diverse nature of your user-base at your disposal.
Time to turn them into a team.
They are, by and large, a result of a structured approach that mainly consists of engendering mutual respect, inclusivity, listening and reacting to what is in front of them.
I’ve categorised the areas of particular focus into:
Setting the stage
Initial development
Setting the stage
In setting the stage I like to begin to really get to know the people that make up 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.
Using Tuckmans model, a team at this stage is forming. Team members will co-exist, they may exhibit civility towards each other, they will frequently agree with each other.
This veneer of mutual existence does tend to mask the independence of thought at play.
The knowledge of their team-mates is superficial, they just don’t know each other well enough to fully trust one another.
Initial development leading to continuous development
In Part 3 I’ll discuss continuous development in more detail. Continuous development comprises learning, BAU (Business As Usual) activities and socialisation.
This stage is about incremental improvements that build on the initial baseline established in setting the stage whilst maintaining the behaviours and standards that were embedded during the initial stage.
By now the team should feel comfortable in expressing opinions with each other and with you.
The team members will seek to establish themselves and their relationships with each other.
‘Playing nice’ is a thing of the past.
A good leader will be aware of the friction that can develop amongst the team and should focus on coaching the team through what can be a difficult stage for both themselves and the team.
In Tuckman’s model this is the Storming phase.
The organisation should by now, have an idea of the process and should be aware of the rationale and associated outcomes (not outputs) behind the process.
Don’t be afraid of mixing and matching elements to find the path through this stage.
Prescriptive direction, coached direction, loose direction, spirited debate, disagreement, goal oriented focus, compromise and most importantly, empathy in all things.
If it works for you and the team then that’s the correct approach.
Inclusivity
Aim to create a psychologically safe environment.
This is the single most important action that can be taken in the creation of a well-rounded QA team (or any team worthy of the name).
In my experience, this is not promoted enough, nor understood enough and is always the poor cousin in a lot of workspaces.
The sad thing about this is that organisations never get to experience the increase in both output and quality-driven outcomes that a team operating in a supportive, psychologically safe environment can deliver.
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 an initial layer of filtering on the more extreme biases.
The job here is not to replicate existing policies but to create an environment where ideas (both good and not-so-good) can be shared without fear of outright rejection, retribution or ridicule.
Providing a psychologically 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 beginnings of 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 that occur within the team.
The real 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, critique and collaborate to achieve the goal.
Your job in facilitating the initial creation of this agreement 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.
Ensure that historically under-represented sections of society have a place in the team.
Actively listen to those people.
Learn from their lived experiences.
Teams thrive when individual and diverse 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
Acknowledge mistakes
People are imperfect.
People make mistakes.
I make mistakes.
You will 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, I will be wrong, I will make errors of judgment, don’t be reluctant to point this out”
Be ok with being vulnerable, you are an imperfect person.
This is not a throwaway attitude to adopt, it should not be treated as a bumper sticker.
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.
Ultimately, you are responsible for the teams mistakes.
You are the leader, do the leader’y thing.
Do the right thing.
The priority here is to help the team and yourself learn from each and every mistake.
Be Accessible
Everyone has worked for a lead or manager that appeared to 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, learn enough to be dangerous.
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 andmodify if required.
Your team are more likely to listen to you if your open-door policy is a real, actionable policy and not vapourware.
Have an 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.
Live 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 openly communicate amongst themselves and with you.
Win-win.
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 to.
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.
The phrase praise in public, criticise in private is very useful.
One of the signs of a growing team is the ability of the team to hold each other accountable. This is why I prefer to air mistakes in public (including my own) and allow the team to discuss corrective actions and learning.
I try to avoid personalising the mistake as this can trigger a defensive stance and damage trust. The goal is for the team members to self-police.
An individual follow-up with the person(s) is undertaken at the soonest possible time to provide feedback.
Praising in public is incredibly important, I use standups (the offline portion) and also utilise any mechanisms provided by the organisation to reinforce this praise.
Note: the team agreement will help in reinforcing this.
Adherence to standards
Set baseline standards with the team, but be open to change.
They baseline standards aren’t set in stone but you will do your utmost to respect the opinion of the team 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 support between the business and themselves.
This may entail being the buffer between the team and stakeholders.
This may entail uncomfortable conversations with stakeholders that want more than the team can give, but it is a necessity.
Acting as a 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 and relationships.
It does not mean being a surrogate parent.
It means being a responsible leader who tries to embed leadership principles, including exposure to conversations and interactions outside of comfort zones.
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 independently 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 coach and develop 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 per quarter.
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 efficiency 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.
This result is measurable and evidence can be obtained via a simple report / number of debrief sessions undertaken.
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 achievable yet 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.
Regular, useful, 121’s should minimise the possibility of missing an agreed objective, this falls on the leaders shoulders.
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 personnel and can (and should) provide tangible benefits across the team.
I coach objective creation as being analogous to a user story with the objective being the user story and the key results being the sub-tasks.
This does rely on your team understanding what a *good user story looks like.
Or y’know, SMART, people like SMART.
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.
I prefer to track these outside of 121 sessions but I leave this up to the team members.
It’s their 121 after all.
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.
Establish regular feedback sessions from the team, for the team
As wider team members operate in individual agile teams, this allows those members a centralised setting to discuss their work, ideas, successes, problems, failures etc.
This is for the wider function team.
Set up a community of practice.
Hold regular formal or ad-hoc sessions to discuss the issues, both visible and hidden.
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 and for recording the content of the session.
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.
This is not a retrospective-lite, it is a chance for those who may not work on the same team to gather and share experiences.
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 or storing in the individuals secure storage only. The notes should only be shared between the two of you.
It allows there to be a historical trail of what was discussed, actions taken and topics for the next session. This also acts as an aide-memoire when appraisal season rolls around.
Make them informal.
For those office-based, an occasional off-site visit to a coffee shop can change the dynamic.
Don’t judge.
Allow the individual to express themselves.
Actively listen. It’s their 1:1.
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 individuals.
Prepare for the 1:1 by reviewing past sessions.
One of the ways I do this is via a 121 agreement, this is a set of rules that articulate the responsibilities for the scheduling and content of our 121's. These rules are agreed upon and placed at the beginning of each team members 121 living document.
“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
These should be created and defined by the team.
Outline the importance of the team interactions with each other.
The object here is to create respect between team members.
Trust will follow.
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 random, useless meetings?
Do the meetings have a purpose and agenda?
Do they outline why invited people should attend?
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 (sort-of) where I tweeted (or x’ed) pre-space-karen where I shared presumed nuggets of learned QA wisdom and upset a few echo-chamber individuals in the process.