Also known as the ‘Power of 3’ / the ‘Triad’ / the 3 Amoebas.

The 3 Amigos (3A) is an incredibly powerful tool in a team’s approach to continuous testing and the delivery of a high quality product.

The other title could be:

but that doesn’t roll off the tongue like ‘3 Amigos’

A 3A session will generate buy-in from people who have traditionally been excluded from the process of knowing what they’re building, we trust the team to do the ‘how’.

In this post, I’ll explain what a 3A aims to achieve, why it’s beneficial, who should join, and how a typical session works.

My criteria is my own successful model from the past.

However, it’s just one approach.

I’m sure many other effective models exist out there.

Which brings me to the What.

Outcomes

• It covers these main questions:

  • Do we understand the problem we are trying to solve?

    • Use the structured discussion format.

  • How do we know if the problem has been solved?

    • Usually in the form of testable ACs.

  • What are the risks involved in delivering the story?

    • Identification of these can focus the team.

    • Mitigation(s) can be identified.

    • Allocation of effort can be identified.

    • A quality deliverable is put front and centre.

'What-if?' questions should be the primary approach.

The What

The 3 Amigos in software development has been around in some form or other for a while.

The earliest reference I’ve been able to find is from George Dinwoodie’s blog.

It mentions a presentation called "A Lingua Franca between the Three (or more) Amigos," posted on Thursday, February 25, 2010.

Not much about the mechanics of the 3A in that presentation.

It’s a great reminder that there were individuals who were articulating the need for greater communication and collaboration in software development during the period when Agile and BDD were gaining mainstream acceptance.

This was before the legions of snake-oil Agile spawning to repackage what is (and should be) a relatively logical, lightweight approach to software development.

This brought me to a great stickyminds article from 29 November 2011 called The Three Amigos: All for One and One for All.

I’m sure that if there’s an earlier reference, I’ll be corrected at some point.

At the time of writing this, that’s over 13 years.

I’ve been a strong advocate of the 3A for the past 10 years.

The implementation and subsequent refinement of this into teams I’ve worked with has increased the ‘quality’ and value of the resultant deliverables.

Every.

Single.

Time.

The 3A is as simple as it gets.

3 stakeholders with a vested interest in delivering a piece of functionality gather to discuss a user story with the simple intent of creating a shared understanding of the user story / desired functionality / feature.

This shared understanding is illustrated in several ways:

Concrete examples of the behaviour or feature usage of the functionality
[Example Mapping in BDD-speak]

A more well-rounded user story.

Fewer assumptions and misunderstandings about what the feature is supposed to do.

Testable acceptance criteria.

Quicker refinement event.

The Why

The root cause of ‘most’ defects I have encountered (YMMV) has not stemmed from the implementation-side or code-side of features.

They may have manifested themselves in the implementation, but that’s not where the misbehaviour was seeded.

‘Most’ have occurred due to misunderstandings that have embedded themselves into ways of thinking.

Into those places where A ‘knew’ what B was thinking.

Into those places where everyone thought everyone else was on the same page via some as-yet-unproven telepathic ability.

Into those places where the obvious morphed into the not-so-obvious after the fact.

Long before a line of code had been written.

Long before a test case had been consigned to the land-fill of straight-jacket thinking.

Mistakes happen, always do, always will.

People are going to people.

With all the hype surrounding Artificial Impediment Intelligence, I would hazard a guess that the majority of software is still developed by humans with all the attendant human frailties.

The defects I’ve encountered have stemmed from a misunderstanding of what is being built, not how it’s done, this lack of understanding leads to mistakes in implementation.

Building the right thing vs Building the thing right

Dev teams are full of clever people.

One issue is that they often believe other clever people think just like them.

Alignment on what needs to be built tends to be a given, right up until the point that it isn’t.

The 3A can bring this alignment.

It allows the smart people to focus on building the thing right because they understand how to build the right thing.

It is not a panacea for your quality ills.

It is not a silver bullet.

It requires commitment, openness, and a willingness to challenge.

As John Ferguson Smart articulates with clarity here.

It has been traditionally implemented (YMMV) as one of the tools used as part of applying the principles embedded in a mature Behaviour Driven Development (BDD) approach.

I’m not aware that it’s a core part of BDD practices, it just so happens to appear tailor-made for the Discovery-Formulation ‘structured conversation’ phases of a BDD approach.

I haven’t seen it implemented outside of usage of the principles of BDD but I have no doubt it could seamlessly fold into any of the other development models and approaches available.

It dovetails perfectly into teams that have adopted an Agile approach.

Those teams that Are Agile, not those who Do Agile

As with any other development tool, it can (and frequently is) implemented poorly, resulting in sub-optimal results for all concerned.

The Who

Or, in nerd-scrum speak, the Developers and the Business.

There are nominally 3 people — A representative of the business (Product Owner / BA), a representative of the coding function (Developer) and a representative of the test function (Tester/QE/whatever new titles a company decides to allocate to their testers for that morning)

You can (and should) involve other specialisations (DB / Network / DevOps / Designer / Person x) if you require it.

Just be aware that for each additional person, the lines of communication will increase exponentially, this in turn increases the chances of misunderstanding and miscommunication.

One of the very anti-patterns that the 3-Amigos is designed to mitigate.

The How

The 3 Amigos is lightweight by design.

The points below could be considered good practice and adoption of these will help to minimise / prevent defects from being introduced into the deliverable.

I’d encourage each team to find a method that works for them, as long as the primary questions detailed in the outcome can be articulated.

• Use the WHeReAS mnemonic as advocated by the Rapid Software Testing (RST) course delivered by James Bach and Michael Bolton

• Each specialisation is encouraged to contribute towards a meaningful discussion that results in a shared understanding of the desired functionality prior to refinement by the team as a whole

• It is a chance to ask questions about:

  • the value statement / background / description contained within the story

  • the test data

  • the testing activities required to meet the team’s DoD

• The use of an independent, critically-focused mindset to uncover and drive out assumptions.

• The use of subjective terms 'quickly' / 'like' / 'similar'.
  These are common flags that would deserve closer inspection and discussion to uncover the intent.

• The story should be approached with a detail-oriented mindset (to a point).
  Teams may face a real risk of paralysis-by-analysis, especially in the early stages of adoption.

• The QE will be primarily responsible for an initial sense-checking of syntax and titles.
  How can statements be misconstrued?
  Can claims be shown to be true?
  Can claims be falsified?

• A natural by-product of this approach is that a quality-driven mindset embeds into the team as a whole as they get more familiar with the sessions.

• Initial Acceptance Criteria (ACs) can be defined as part of the process.
  It's important to understand that the primary purpose is to reveal surface assumptions and create a shared understanding of the required functionality

• ACs defined after the 3 Amigos run the risk of:

  • What was understood at the time of the discussion becomes a fading memory and people are wired to subconsciously fill in the gaps, resulting in inaccurate AC(s).

  • Context switching from a task can lead to inaccurate ACs.

  • Defining ACs at the last minute leading to rushed, poorly defined ACs.

  • Ownership issues can cause the anti-pattern where only the QE function controls 'quality'.

• ACs can be defined following the behavioural approach (Given, When, Then scenarios using Gherkin syntax)
  
  They can also be laid out in a simple 'expected input/output' format in a table or text.
  
  or
  A simple 'expected input/output' format expressed in a table or text

  • UI elements benefit from a simple visual inspection.
    There is no behaviour present within the display of static elements.
    If the display of a particular element is expected as the resultant of an action this would be contained within a 'Then' statement.

  • Behavioural activity (I want to do x to see y) benefits from the Gherkin approach.
    It helps in creating a shared understanding of the expected functionality from a business and user perspective.

  • Using examples of the expected behaviour helps to illustrate rules and constraints.

  • Thinking in terms of 'Demonstrate that...' can also be useful.

• It’s important not to get hung up on a specific, prescriptive means of writing ACs, as teams can spend longer discussing minutiae than actual success conditions.

• When discussing the story, asking the question ‘Can you give me an example’ helps to frame the expectations in a meaningful way.
  Commonly referred to as Example Mapping.

• Team members build their understanding together by asking questions about the examples.
  "what if..."
  "what else..."
  "so that means..."
  This helps them come up with potential solutions.

• During the 3-Amigos:

  • The Developer will be thinking about technical constraints and possible solutions.

  • The QA will be thinking of edge cases and testability concerns.

  • The PO will be addressing business rules, constraints, and assumptions.

  • Nothing stops any of the three from positing questions aboutthe other areas outside of their specialities.

• It is recommended that there is business involvement.
  This will help to ensure that the generated ACs meet with the expectations of the business.
  If the business cannot attend, it does not automatically mean that ACs cannot be generated.
  It does mean that the business will need to inspect the ACs at some point before implementation to ensure that the teams’ understanding maps to theirs.

• Defining ACs upfront also increases the engagement of the developers as they can implement and test their implementation against the defined criteria, which will help ensure that the code delivers against the business expectations

• Initial sessions may appear to be prolonged; this is a natural by-product of the team members getting used to the close collaboration and efficiency of communication a 3 Amigo session demands.
  The pay-off is measured in:

  • Reduced context switching during a sprint to address formal defects.

  • Reduced time spent on the defect lifecycle while addressing each phase of a formal defect cycle.

  • A typical defect cycle (for a single defect) usually results in around 2 hours of work.

  • A typical defect cycle (for a single defect that requires an automated check) usually results in around 2+ hours of work.

• As team members get more well-versed in this approach, the time taken for each session should decrease to around 30-45 minutes.

• If a session spans an hour, it can be useful to have a 5-min break in the middle to allow teams to reset.

• The 3 Amigos should initially be held at the same time each day following a stand-up.

• This builds a useful cadence.
  It avoids context switching due to day-to-day development activities which can decrease engagement and reduces meeting fatigue.

Conclusion

Highly collaborative 3A will improve the quality of the delivered feature / feature-set.

Honest and critical 3A demand high levels of transparency.

Structured and open 3A will assist in mitigating risk.

A highly-skilled QE is invaluable, someone who can adopt a critical-mindset towards the feature and adopt a critical-mindest to the thinking of the other domain experts in attendance.

The time taken to understand the feature more than pays for itself over the course of a sprint by reductions in:

• Misunderstandings

• Observable defects

• Attendant rework.

Introduction

There’s a lot written about the benefits of *automated testing.

There’s a lot of money to be made by tool vendors.

There’s not a lot written about the downside of *automated testing.

A well articulated and well implemented test automation approach is a valuable piece of any development effort.

I’m not anti-automation as a test effort, I’m anti automation-as-a-silver-bullet as a test effort.

All of the below still holds true in the age of AI.

The new starter

You have a new starter. It could be a junior dev.

It could be a junior QA.

It could be a BA.

It could be a PO.

That person will do exactly what you tell them to do when you tell them to do it.

They’ll do it over and over ad-infinitum unless instructed to stop.

They’ll never change unless you tell them to change.

They’ll only observe or check exactly what you’ve told them to observe or check.

If what they observe or check doesn’t smell right they’ll attempt to carry on.

If that smell doesn’t fit with their pattern, that smell will not trigger any curious, conscious, cognitive function.

If what they observe doesn’t equate to what you’ve told them to observe they will stop, unless you’ve told them beforehand to carry on.

If what they observe is as a result of unanticipated behaviour, they may stop.

They may or may not tell you why they’ve stopped.

What they tell you may make sense, or not.

It all depends on what you told them to tell you when unanticipated behaviour occurs.

If something prevents them from completing their primary task, they may attempt to carry on.

They will do this if you’ve told them to.

They will do this only if you’ve articulated the possible interruptions.

They will do this only if you’ve articulated the precise method of recovery.

They won’t comprehend the nature of the disruption and how it relates to uncompleted tasks.

They won’t comprehend the nature of the disruption and how it relates to completed tasks.

They won’t ask ‘why?’.

Your new starter is automated test execution.

It does exactly what it is told to do based on an initial set of commands that were valid at a specific time for a specific outcome.

It can look for one (or a range) of things that it has been instructed to exactly look for.

It has no innate curiosity.

It doesn’t think.

It doesn’t reason (beyond the algorithmic constraints you’ve told it to use, which may or may not be correct)

It doesn’t interpret.

It doesn’t make value judgments.

It doesn’t experience.

It doesn’t question.

It doesn’t utilise context.

It doesn’t easily communicate in a meaningful fashion.

It doesn’t utilise experience or heuristics or oracles (unless you’ve explicitly told it you)

It doesn’t explore.

Automated test execution can provide confidence (this thing works as you’ve told me it should).

Automated test execution can provide confirmation of uncertainty (this is not working as you’ve told me it should).

It can only do this in the context of being formulaic; of following a script; of blind adherence to a set of rules that may, or may not, be correct.

It may detect a non-conformity according to it’s own, or your rule-set.

Once a non-conformity has been detected it will tell you (albeit in an abstract, flat, manner)

It won’t attempt to understand the ‘why’

It won’t use critical thinking skills to work around and through the non-conforming behaviour.

It won’t use these skills to uncover related non-conforming behaviour.

It won’t use heuristics.

It won’t use models.

It won’t use an oracle.

It won’t use *common sense.

It won’t stop execution based on a feeling or a hunch.

The non-conformity may be a defect.

The non-conformity may be a feature.

The non-conformity may be environmental.

The non-conformity may be the result of a misunderstanding in communication.

The non-conformity may be as a result of the test code itself.

It has used no cognitive reasoning.

It won’t vary it’s approach.

It won’t attempt a similar process using a different variable.

It won’t attempt a different (but similar) process using reasoning and modelling (implicit or explicit) to compare the two and reason to an outcome.

It won’t use logs to attempt to understand.

It won’t reference a design.

It won’t tap your colleague on the shoulder / fire off a slack message to ask for a second opinion.

It won’t interrogate stack overflow.

It has simply followed the rules.

It just is.

Conclusion

Automated test execution never has, and never will be, a panacea to your perceived quality ills.

Introduction

Agile, just the word alone, with 0 context, appears to polarise opinions within software development circles.

The way that some commenters opine you’d think it was only second to the pandemic as the greatest evil to befall software development.

The Agile manifesto is 22 years old at this point and I’ve never seen such a backlash or hand-wringing over what, on the surface, seems to be a relatively simple approach to software development based off 4 values and 12 principles.

If you’re interested, the manifesto is here:
Manifesto for Agile Software Development

Much of the backlash appears to stem from the monetisation and snake-oil peddlers / consultants that appear to plague the industry promising cure-alls.

The development equivalent of fairground barkers selling a miracle cure.

A lot of these seem to stem from the simple fact that teams and orgs are coached (where they are coached) to observe the values and principles enshrined within the manifesto as if they are a sacrosanct set of rules to be adhered to without question or thought.

Just drink this / read this / apply this / attend this and all your development troubles will miraculously melt away…welcome to delivery nirvana.

Your releases are seamless.

Your features are high quality.

Your development practices are a union of hope and applied expertise.

Your product offers value to your target market.

Your customers heap praise on your efforts.

If only.

This isn’t about testing specifically; this is about the tangential causes that ‘could’ have an effect on the quality of what your teams deliver.

I’ve seen what happens when a team embrace respect, the intent behind the principles and apply both their individualism and collective wisdom in pursuit of a collective excellence in what they deliver.

It’s amazing, it’s truly the best experience I’ve ever had and one I’ve never experienced since.

What does any of this have to do with quality?

Everything.

As a SM / QA / QE / Alphabet title, your role is to be aware of those behaviours which could impact quality, it isn’t just about demonstrating that a product fulfils some defined requirements articulated in user stories.

It isn’t about some pseudo-random green tick on a pipeline.

It isn’t about a coverage percentage based on not actually knowing what 100% looks like.

It’s about team behaviours. They can, and do, impact every facet of a team’s output. They will have a corrosive effect on the quality of what your team produces.

I’ll look at what hinders teams from being truly agile (not in the context of airy-fairy-post-from-the-comfort-of-twitter-look-aren’t-I-on-the-edge) but real mis-steps I’ve encountered as a team member in the Daily Scrum, driven by Scrum Masters and Product Owners who should really know better, as a team member helping to drive quality into our releases and as a Scrum Master helping teams to be truly open, transparent and effective.

Basically, how do you identify when Agile turns into F’ragile?

None of these are explicitly called out in the Agile manifesto. You wouldn’t expect that though, they were created as an aspirational guide, not a rulebook to live and die by as some would have you believe.

Quality engineering is an activity embedded within the manifesto, it should never be a tick-box exercise that is solved by attending events, demonstrating a feature or constructing lots of scripts that run without manual intervention.

It is by and large a community effort.

My Agile gotcha’s — The Daily Scrum perspective

You may have experience of these, you may identify with these dysfunctions right now. These are the gotchas I’ve experienced the most and the ones that will directly affect the quality of your deliverables.

YMMV.

I’ll add what has worked for me and the teams I’ve been involved in.

This mainly focuses on the Daily Scrum / Standup though these can be applied to pretty much any event.

Quite a few anti-patterns can (and do) surface in other events, and during the course of a sprint.

Pointless meetings

Lots of people moan about pointless meetings, ceremonies (events) get bundled in and derided with the resultant demotivating attitudes.

This becomes a circular descent to team dysfunction.

They have a valid point; pointless meetings are counterproductive.

Quality impact

Meetings without a clear, pre-published agenda result in spectacular talking shops that wind through numerous topics without any resultant value.

Meetings without actionable, measurable outputs result in fractured activity, not really knowing if the ‘what’ you’re doing is answering the questions (if any) outlined in the original meeting.

Meetings organised and/or run by someone who does not facilitate. This normally results in grandstanding / the appeal to authority fallacy / loudest voice wins.

Do this:

Every meeting is communicated in advance as far as practical with a structured agenda. This allows invited participants to prepare. It allows those invited to work out if they need to be there.

Attach an agenda

Capture actionable, assignable, measurable outputs

Control the meeting.

Set ground rules (In advance or when the meeting starts)

Vote with your feet (or virtual feet). If you aren’t getting anything out of the meeting, leave. Contact the organiser after the meeting and explain why you left. Any mature facilitator will be grateful of the feedback, chances are you weren’t alone, you just had the courage of your convictions.

Status Updates

The Daily scrum is an opportunity to tell a story, to identify what you’ve done and how you’re doing it.

It’s not a point and click exercise.

It’s not a by-the-numbers event.

It’s not about calling out a ticket by it’s number. “Where are we on 16656?” doesn’t help anyone.
 It’s not about calling on people to provide an update.

Giving soul-less status updates don’t help anyone, let alone your team.

Quality Impact

Providing an unengaging ‘what I did yesterday, what I’m doing today, my blockers’ update leads to 0 engagement and 0 interest.

They are robotic in nature and all too frequently devolve into single line sentences that offer no nuance.

It allows people to switch off until it’s their turn in the spotlight where they can then follow the same uninspired formula whilst everyone else switches off.

Do this

• Walk the board, describe what where the story is in relation to getting to done.

• Describe what the feature is designed to accomplish.

• Describe any testing that has happened.

• Describe any obstacles and how you overcame them.

• Describe how your activity progresses the ticket.

• Describe what the next step is.

• Engage other team members.

• Give enough information to be helpful to the team without devolving into a stream of consciousness.

• Tell a story.

The team should engage, ask questions, offer opinions, help and advice.

The team should have enough information to know where the story is.

All in the name of progressing the story to done.

You aren’t a time lord

Respect probably lies at the heart of being Agile, respect for your time and the time of others in your team.

Time-keeping is one of the biggest drivers in any successful ceremony.

Daily scrums / Stand-ups should happen at the same time every day, this isn’t death by process. It means that they are predictable in their occurrence and duration, it means that teams can effectively plan the next 24 hours of effort to help get the stories in play to done.

It helps ensure that context switching is kept to a minimum and only those things of value are discussed.

It helps to focus the team and the contributions of the team as a single entity towards successful and timely deliverables.

Quality impact

When team members are late to ceremonies it is indicative of a team that doesn’t respect each other’s time, it is also indicative of a general lack of interest. It has the effect of signalling to others that this isn’t something to be taken that seriously, this can and will have a ripple effect on the engineering activities that happen during the course of a sprint. If a team member turns up late, how much have they missed, what insight is lost that could have mitigated an issue or mitigated a bug or observed a flaw in a test idea or suggested a further test activity or clarified a misunderstanding. You can never get that time back.

The solution is relatively simple.

Do this

• Be on time for events.

• Be mindful of your responsibility to the team.

• Set a reminder 5 minutes before, aim to be there a minute or two before it starts.

• Respect those team-mates who do turn up on time.

Your time is no more valuable than theirs.

No, you can’t pick and choose other stories…just because you want to

Kanban boards are usually structured in a top-down, highest priority first manner.

This means that those stories at the top have a higher priority than those lower-down.

All too frequently I’ve seen team members complete a task that they’re comfortable with and then pick a task from another story lower down in the stack whilst there are still stories in play above them.

I understand that there are many talented developers on teams, I also understand that there are individuals that don’t feel the need to play by any defined set of team behaviours.

Quality impact

It doesn’t show joined-up thinking. It shows that ‘your’ work is more important than the teams work.

Each team member has a responsibility to the team to progress the current stories in play.

Attention is diverted from the most important stories, valuable time is spent discussing the details of a task that, at that present time, isn’t that valuable to the team and the overall goal of getting stories to done.

It shows a siloed mindset.

Do this

• Once your assigned task has been finished, ask if anyone on your team needs help with theirs.

• Be aware of people strengths and weaknesses, be empathetic.

• Offering to help someone else is a good thing.

• Be okay with stepping out of your comfort zone to learn something new about the feature, a way of thinking, a new technique, an approach.

• A QE is working on an automated test, you’re really good at design patterns and code, they are really good at test design. Pair with them, share your expertise.

• You’re also not as good at test-designs, pair with them, ask them to walk you through their thinking, look for inconsistencies and flaws in their model.

• The task you help someone else with may be completely alien to you. That’s a good thing. Whatever your level of expertise, you will know more about the thing than you did before. You will also promote trust and team-working, it may not be explicitly visible, it will make a difference.

No, you really can’t work on more than one thing at a time… No. Really. You can’t.

I see this repeated with alarming regularity, one person has >1 ticket(s) in various stages assigned to them(selves).

You aren’t a magician.

Quality impact

Context switching is a hidden killer, it’s obviously possible to entertain several ideas in your head at any one time, we do it every day.

You may think you are giving a problem your full attention to the exclusion of the ’n’ other tasks you’ve assigned yourself to.

Chances are you aren’t.

This will manifest in the quality of the output, mainly due to the context switching, lead-in / lead-out time to focus back on the thing.

Do this

• Work on a single task at a time. Make others aware that you’re focusing on a singular task.

• If people request assistance, discuss an appropriate time for it so you can focus on your task.

• If you’re working on a task and you can’t make further progress, identify the why, identify if anyone on your team (or another) can assist. If there is a blocking issue, articulate this in the ticket. Move it to blocked so that it can be discussed at the earliest opportunity. Keeping it in active will not help the progress of the story to done (unless you’re actively engaged in resolving it) in which case why would you assign another ticket to yourself?

• Story progression is king (or queen)

Done most definitely doesn’t mean “sort-of / mostly / yeah..but”

Most well organised teams will have a Definition of Done (DoD).

This is a set of explicit criteria that should be defined by the team that will act as confirmation that the story in question is potentially releasable.

The team should have committed to the criteria contained within the DoD.

Quality impact

The whole point of a DoD is to gain confidence that the story / feature has had all the requisite activities (code / test / review / documentation / automation) undertaken.

Any ticket in the done column is ready for a potential release to the client.

If there is uncertainty from the team as to the status of the artefact in done then that implies uncertainty in the process leading to the ticket being placed in done.

This in turn will lead to uncertainty of the correctness of the developed story / feature.

It’s not a blame-game, this is an opportunity to inspect and adapt.

Do this

• Ensure that as a team, you revisit and confirm the criteria outlined in your DoD.

• Add criteria if necessary.

• Remove those that aren’t required.

• Good practice is to regularly revisit the DoD / DoR / Way of Working, especially if there is a change of team member.

• If there any commonalities in done artefacts that would impact a potential release, add / amend criteria to cover those eventualities. The DoD can be modified at any time (as long as the discussion is had with the team)

• Create a Final Quality Check (FQC) task that outlines a simple checklist of things to be covered off, this is the final task to be completed. A simple checklist also means that any member of the team can pick it up to complete (More about an FQC in another post)

Stick to the story / task being discussed

A Daily Scrum is an opportunity for the dev team to plan out what the next 24 hours looks like as a team.

It should be story focused. i.e how do we (as a team) get this story to done.

Quality impact

If the conversation deviates from one story / task to another, or irrelevant details creep in to the story being discussed, a teams focus will also shift and attention will also shift.

Team members may checkout in terms of attention.

The story that was being discussed now becomes an afterthought, the risk here is that there may have been contributions from other team members that now aren’t heard.

The time-box will be violated, despite what a lot of people say, this isn’t the cardinal sin that a lot would have you believe it is, this does run the risk of people becoming bored. This in turn provides more ammunition to those that say that Agile is a hindrance, not a benefit.

Do this

• Promote the fact that all members of a team have a vested interest in ensuring that a task is given it’s due attention.

• Bring people back on topic, be polite.

• If the topic is that important to people, ask them to discuss it post-standup, anyone who has a vested interest can then attend the ‘offline’ portion and those who aren’t interested can get on with implementing the plan discussed in the standup.

• Don’t wait for the SM to interject, they aren’t your mum (or dad)

• Create (and use) a team safe-word. 
  ELMO (Enough, lets move on), Banana, Mayday.
  This word can be used by anyone. The purpose is simple, anything that detracts from the plan, anything that detracts from a high-level understanding of progress can be pushed to the offline portion.

Keeping JIRA / Kanban board in sync is not optional

Just like meetings, JIRA (or whatever flavour of management tool is in use) are derided on a regular basis. This is normally a result of mismanagement and perception of what the point of these management tools are for.

Quality impact

JIRA and the kanban board should be kept in sync.

One contains detail that won’t be apparent by inspecting a board, both act as an immediate checkpoint as to the progression of a ticket.

If this progress is not reflected in either, it’s all too easy to pick up a ticket in JIRA that is already in progress on a board, it’s all too easy to undertake work that has already been done.

The result is that rework may be required or someone has to interrupt their progress to discuss what has been done and update the affected tickets.

Either way, the quality impact is manifested via distracted team members and confusion as to the ‘actual’ status of a story.

Do this

• Document progress, the task / ticket is not completed until both boards have been updated.

• Modify the DoD if required.

• If you’re remote and you don’t utilise a physical kanban board it can be seen as not so much of a problem but the point still remains that JIRA / Management tool should be the single point of truth that a team member can reference to ascertain work done.

’15 billion conversations at once’

Events are conversation pieces.

They are designed to facilitate conversations and stimulate ideas.

This is great but this does come with risks to be aware of.

Quality impact

Walking the board is a fantastic way to communicate progress, this can become undone if several conversations happen at once.

It also displays a lack of respect and focus if a person is speaking.

It also displays a lack of respect for the team and the event itself.

Attempting to follow >1 conversation(s) is nigh on impossible.

Speaking over over people will lead to other people speaking over you.

The net result is that ’n’ number of team members won’t understand the current progress…neither will the offender.

Do this

• Be aware and conscious of other team members speaking.

• If you have a point to make, wait for an opportunity, allow the team to hear what you have to say.

• Take side issues offline.

Conclusion

The daily scrum is the one opportunity each day for the dev team to get together to plan and discuss what the next 24 hours look like in their particular world.
It doesn’t preclude small groups from talking, it doesn’t preclude individuals from being asked / asking for help.

Dysfunctional standups will hurt you and by extension, the quality of what you and your team produce.

• A well run, engaging, conversational Daily Scrum sets teams up for success.

• It’s not a status update.

• Quality is not just code.

• Quality is a people and perception problem.

• Quality is a concerted effort from:

• Quality Scrum Masters

• Quality Devs

• Quality Product Owners

• Quality Designers

• Quality Stakeholders

• Quality DevOps

• Quality SRE’s

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.

“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 those teams.

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 organisational expectations.

Communication skills, attitudes and the transferable skills can be coached over a period of time.
I look for those qualities that are infinitely transferable regardless of the tech stack.
I want to build teams that last, even when team members move on (as they will, and as they should).

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 manager / lead.

• A conclusion on 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 on what I’ve discussed and a primer for the next post.

Part 3:

• 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?

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 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, or are receptive, to learn of their own, existing, limitations and are unafraid of improving these limitations. 
Knowledge of tool-sets isn’t a factor and isn’t something I prioritise.

Qualities I look for in a competent QE

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 leader, 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 obtain as a QE 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 actively 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 QE role and the challenges that can be encountered.

• An ability to communicate information at the appropriate level dependent on the level and person you’re communicating to.

• Exercise the mental fortitude to challenge existing wisdom.

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 limitations.

These limitations don’t disqualify you from being a leader for your team, they will ultimately drive you in becoming a better lead.

There’s a difference between team conversations and team decisions.

Part of your job, just like the day-to-day work as a QE, 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 QE faces on a daily basis.

It’s also important to understand that experience (of different types) is no indicator of expertise.

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 or time spent gaining domain knowledge.

If someone has spent 10 years in a particular role there’s no logical conclusion that leads to them being a good leader.

It also doesn’t apply that because they have an in-depth knowledge of their function they can automatically transition into someone who can make sound decisions on behalf of, and for, the team.

It means that just because they have an encyclopaedic understanding of the domain that they have the temperament or critical thinking faculties to facilitate the growth and maturity of the team.

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 QE:

• How many of those qualities do you currently possess?

• Which do you possess but need to improve on?

• Which of those qualities does your lead currently exhibit?

• If they are missing qualities (in your opinion), be nice, provide constructive feedback.

If you’re a QE manager/lead:

• Which of those qualities do you exhibit?

• Which of those qualities do you need to improve on?

• Which of these qualities do you practice in the team and organisation?

• Any of your engineers are potential leads, which 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 (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.

This is part 3 of the ‘Building a QA team’ series. In this series, I’ve explained what I’ve learnt in the creation of a great team, I’ve also explained the methods I’ve used to create the initial team using a set of shared values. 
In this final part, I expand on the methods I use to help ensure that the team continuously improves:

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

Part 3:

• 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

Build on the foundation that the team has established, not change for change’s sake

This final part will address the methods I’ve used to achieve the continuous, incremental improvements that identify a growing team. 
I also discuss motivation as a key factor.

This includes do’s and don’ts.

Ones where I’ve been responsible and ones where I’ve been on the receiving end.

One mistake I frequently encounter is that continuous improvement is mistaken for root-and-branch change. 
I look for subtle changes that build on the foundation that the team has established, not change for change’s sake.

Ongoing Development

The team has formed, they appear to work well together as a specialist function and for each other and in their own cross-functional team. 
Specialists in their respective cross-functional teams are making the right noises.
 
You’ve helped to create a diverse set of individuals with the essential mix of soft and hard skills who encapsulate what you look for in a high-performing team.

The organisation is aware of what you’re trying to accomplish. If they don’t, socialising the goals and objectives of the team is required. 
At this point it’s very easy to sit back and bask in the reflected glory.

This is a bad idea.

The hard part begins now.

As individuals become comfortable (The ‘norming’ part of Tuckmans model), it’s very easy to fall back into behavioural norms that can disrupt the hard-won team ethos.

Learning

It is never just about learning a new framework or how to implement a pipeline.

Secure a training budget
People like to feel valued.
 
If budget permits, secure an amount to allow people to attend training to learn a new skill or purchase a book.

Create a process to make this as easy as possible and communicate this process to the team.

If the budget is not available, make use of the multitude of free courses available online such Test Automation University or reputable sources on youtube / linkedin.

It does not have to be technical training.

A QA is a multi-faceted role that relies as much (if not more) on learning about the human experience, critical thinking, negotiation skills, conflict resolution, human-centered design, risk detection and management.

It is never just about learning a new framework or how to implement a pipeline.

There is no downside to this approach.

As long as the course can show a tangible benefit to the function of the team and the individuals role within it then everyone wins.

Learning sessions
Enable the team to spend 10–15 minutes a day researching a technique, reading a blog or book, visiting a forum, experimenting with a tool.

It can be in their specialisation or a specialisation they are unfamiliar with, anything that helps them to be better QE.

It can be design / UX / development / architecture/team-working/Agile ways-of-working. Anything that stimulates thinking.

It has the added benefit of increasing their knowledge base which can then be filtered through to the rest of the team.

There may be concerns (usually from stakeholders) that 10–15 minutes a day will have negative impacts on productivity.

Address these issues diplomatically by pointing out the benefits.
The team are not producing footballs in a factory.

If individuals feel that it impacts their productivity, it might be useful to dig a little deeper as this may mask time-management issues.

Promote learning and experimentation in the QE space
It’s important that teams are populated by diverse skill-sets and experience.

The QE function is ever evolving.

New ideas, new tools, new patterns, new methodologies are a constant.

Allow the team to collaborate with those inside and outside of their skill-set to ingest new ideas and approaches.
 
Promote lunch and learns / brown bag sessions / lightning talks as a means to communicate the output of these sessions.

Allow the team to experiment based on the output of these sessions.

Every day should be a school-day.

Promote learning in the domain
Being experienced in a domain is a double-edged sword.
 
On the plus side, the combined knowledge and experience can result in a near instantaneous idea of how the ‘thing’ can be tested.

On the negative side, this combined knowledge and experience means that in the process of accumulation, bad habits and (possibly redundant) knowledge would have been picked up which can result in sub-optimal testing activities being undertaken.

This is known as front-loading.

It can be very useful to pair up less experienced team members in pair testing sessions with the less-experienced team member acting as a navigator.

Those less experienced can bring a fresh insight into the domain under test.

Business As Usual

Gain support and trust from stakeholders
None of the methods outlined have ever worked (for me) without support from stakeholders.

It is up to you, as a leader, to articulate and promote the benefits of these methods to these stakeholders.

For example; Some employers will feel unease at allowing off-site meetings.
 
Anything away from the console / IDE is not ‘real’ work.
 
In my experience, this appears to be the norm in organisations that have little to no trust in their employees, usually identified by the use of antiquated, outmoded time-tracking processes.

If numbers are all that matters, then you and your team will be well on the way to becoming a number.

There are options available.
 
You can stay and attempt to persuade and educate or you can leave and find an organisation that understands the business benefits of trusting employees.

Don’t micromanage
Micromanagement is a management style that attempts to excessively control the work of people in the team.
 
No team member has ever said ‘I’m such a better team member for having Jim scrutinise each and every decision I make in my day-to-day work’
Don’t do it.
 
You are building a team that you trust to make decisions given the best information they have at the time. 
It is a guaranteed way to destroy hard-won trust. 
Don’t do it.
 
You are building a team that you would like to think independently.
Micromanagement is a guaranteed way to introduce paralysis by process. Don’t do it.

If the working day is spent peering over the shoulders of the team attempting to verify each element of their work, it will leave you room for nothing else, a guaranteed way to burnout.
For the team, you absolutely have to allow the team to breathe and decompress.
Don’t do it.

You are building a team that thrives on ownership. 
It is a guaranteed way to stifle that ownership. 
Don’t do it.

Be aware of how much time is spent controlling members of the team.
You should be constantly evaluating your approach and interactions. 
If in doubt, ask the team.
They are best placed to tell you if they are feeling micromanaged. 
Act on their comments.

Consistent overwork is not a virtue
Don’t confuse commitment and ambition with overwork.
 
There will be times when a degree of stretch from the team may be expected. 
Burning platform, critical defect found the afternoon of an evening release, a client that has decided A===C and not A===B.

Don’t allow it to become the norm.
 
Allow the team to self-police in this respect.

Maintain an awareness of who is doing what hours.

Some members of the team may require protecting from themselves.

Pointless meetings
Promote the law of two-feet for both meetings organised by yourself and meetings organised outside of your team.

Pointless meetings are regularly in the top concerns of any list of employee gripes.

Show your team what *good looks like.

Provide context and/or an agenda for meeting invites. Give them a reason to attend.

Book the at the beginning or end of the day if you can.

If you work within an Agile framework, make the events and ceremonies count.

Coach your team to facilitate useful meetings.

Take breaks
Don’t allow the team to be a slave to the console or the whims of others outside their team.

If they feel fatigued, they should take a break.

Get some air.
 
Go for a walk.
 
Take their lunch.

They shouldn’t need to ask permission, they aren’t in school.
 
Encourage other team members to do the same.

Mental health issues as a result of burnout aren’t bumper-stickers or slogans.

Left unchecked it can have serious repercussions, both for the team and more importantly, the individual.

Take leave
Regular leave is essential to take stock and recharge.
 
Institute a no-email, no phone-call, no app-on-phone policy outside of work.
 
Promote the use of a ‘marching-order’ email sent ahead of leave that contains just enough information to allow colleagues to understand the what and when of their current workload.

Don’t use email or messaging as a substitute for active F2F communication
Where possible, leave your desk and talk to the person.
 
The rise of hybrid and remote working has made this much harder to accomplish.

Harder, not impossible.

Be respectful of interrupting that person if they have their head down on a problem or a status of ‘Do Not Disturb’.

Make a mental note or create a sticky-note to talk to them later if required.

Don’t just type out a fire-and-forget message or email.

When messaging or emailing, if the first line is Not-Urgent! the first line of that message will display on the recipient’s machine as a notification and when they glance at it (as they inevitably will) the distraction from their task at hand will hopefully be minimised.

Look out for each other
The team should help each other.

They should learn to recognise the normal behaviour of their peers.

Stress the need to be proactive.

They should take time out to talk about their day and actively listen in turn.

If team members are concerned about a colleague they should attempt to discuss this with them and if necessary, escalate.

Buddy up
Create a buddy system.

The aim is to involve the new starters in the team ways-of-working and team culture.

As per the team make-up, you will have a mixture of personalities.

Allow the team to define their buddies but be aware that ‘like’ will often gravitate to ‘like’.

In the case of strong personalities this usually leads to dynamic, but potentially, explosive conversations.

In the case of the shy, retiring types this could lead to very little in the way of useful outcomes.

A more useful approach is to match opposites.

It is also useful to mix up the pairings over time.

Mixing up the pairings will expose team members to different styles, opinions and knowledge.

The final benefit is that it enhances the individual growth as each type has to adapt their style to effectively communicate with their peers.

Walk the walk
Be a role model to your team members and practice what you preach.

Be vulnerable, no-one thinks you will have all the answers.

Team members will appreciate the effort.

Like it or not, your position carries the weight of implied authority.

People don’t expect you to be a paragon of virtue, they do have a valid expectation that you respect and acknowledge the privileged position you are in.

Socialisation

Encourage social gatherings (In-person and remote)
The team socialising outside the confines of a work environment has the benefit of lowering barriers that exist in the workplace.

This allows for a more relaxed environment in which issues can be discussed without fear of misinterpretation by non-team members who may not be privy to the underlying history or background.

For hybrid or remote teams, a no-strings video call inside and outside of working hours can be useful.

Attend social gatherings (In-person)
You may find that reticent individuals will open up due to a change in environment during off-site get-togethers.

As a leader you must attempt to approach these conversations with an open-mind, more often than not you will acquire information about individuals that may help in your interactions with them in the workplace.

Conversely, team members will also gain information about you.

However, don’t force work based conversation, if you are alert and present, you will gain knowledge on specific behaviours regardless of the topic of discussion.

Get to know the team
A good team lead will understand the meaning in being able to ‘read the room’.

Make time to get to know your team on a personal level.

This approach will vary between individuals.

Understanding the team on an individual level allows a lead to sense when tensions arise / interactions are fraught in a group setting.

They can read the room.

It also has the advantage of being able to step in early to head off potential misunderstandings or conflict.

The ability to read the emotions of others is linked to ‘social intelligence’ which, in turn, is linked to performance on team-based problem solving tasks.

Allow the team to get to know each other
Relationships are established via regular interaction, both positive and negative.

Healthy friction is a sign of a maturing team.

Foster break-out sessions or informal get-togethers.

A late Friday afternoon decompression session where work talk is off-limits can bond and benefit the team immensely.

Don’t feel slighted if the team decides to run a session without you.
This is not about you.

“If in doubt, just be kind”

Create career path(s)
The aim is to retain personnel.

The aim is motivate your team to be the best of themselves.

A structured path for career advancement is an invaluable tool in making people want to stay with the organisation.

Replacing personnel is very expensive.

A clear and achievable career path should be articulated to the team.

There will be occasions where individuals fall short of a particular milestone.

This is to be expected.

How it is addressed is key.

As individuals reach a particular milestone they should be rewarded.

It’s worth bearing in mind that not everyone has aspirations to be a leader, different people have different motivations.

Continuous motivation
Once an initial team has been formed the goal is to ensure that the team continuously improves.

An awareness of what motivates people will help, people are motivated by:

• Achievement

• Feeling valued

• Ambition

• Mastery

• Empowerment

• Incentives

• Salary

• Helping others

There is no ‘one size fits all’.

Nurturing a safe, supportive and inclusive environment is key.

All too often I’ve experienced the ‘Continuous improvement’ mantra that, on closer inspection, amounts to nothing more than empty words, unfulfilled promises and box-ticking.

Don’t become part of that particular problem.

Finding out what motivates people is the first step, their goals can then be tailored towards this motivation.

This information is very useful when discussions with the team occur as you will have an overview of individual expectations which will inform the overall team outlook.

People naturally grow in person and their career.

Don’t be an obstacle to this growth.

Conclusion

Building a team is not an all-or-nothing exercise.

Gathering the people is relatively simple.

Creating the conditions that engender teamwork and trust is more complex and takes time.

The methods outlined above will work but they have to be applied within the context of the organisation you are building the team within.

If in doubt, just be kind.

It takes time and real effort.

There will be highs and lows.

People are, on the whole, intelligent and caring.

Treat them as such.

They are subconsciously aware of face-value efforts and will react accordingly.

Be true to yourself and understand that not everything will go to plan.

Be prepared to back your team.

Some may question the value of these methods versus ‘real work’ .

If you quantify ‘real work’ as sitting at a console for hours on end churning out slabs of code or writing tedious test scripts then this post isn’t for you.

I would posit that forming well-rounded relationships amongst peers will return far more value in developing quality software than any amount of solo effort.

The benefits to an organisation in high-performing teams cannot be understated, yet somehow they frequently are.

Pre space-Karen you could find me on twitter (X) where I posted presumed nuggets of hard-won QE wisdom and upset some self-styled ‘thought leaders’ in their clichéd echo-chambers.

Introduction

Any team that follows an agile approach is probably cross-functional.
 
If you’re lucky, you will work alongside Developers, Business Analysts and UX specialists. 

They are specialists in their own right. 

Developers will own the implementation and optimisation of the code they create, if you’re very lucky, they will create unit tests alongside the implementation.
 
A Business Analyst will focus on the requirements of the system to be implemented, they will act as the prime interface between the stakeholders and the team as a whole.
 
A UX specialist is expected to be concerned about designs, look and feel and colour palettes.

So what of the QE?
One of the expectations of a QE is the ability to think; the ability to evaluate information using a systematic and deliberate approach separate from the mechanistic, ritualistic thinking employed in day-to-day development activities, as evidenced by group nodding / group-think in many team discussions.

That’s ok, the rest of the team are composed of builders, their sole purpose is to create the ‘thing’ that will amaze and delight users in equal measures.
This ensures that bills get paid.

This isn’t to say that builders don’t think, of course they do.

It’s not fair to say that builders don’t test, of course they do.

In the course of building the thing, the builders will make mistakes, they will evaluate what they’ve written, they will refactor and reassess as they go. They will create unit tests that exercise modules or methods or, if you’re very lucky, will practise Test Driven Development.

They may even critically evaluate what they’re building, they may assess against risk in various situations, security, performance, functionality, accessibility…

But it isn’t their primary focus, critical evaluation of the thing being built lies squarely at a responsible QE’s feet.

Before, during and after the thing has been built.

To not do so is an abrogation of responsibility IME.

Everyone else can be the optimist.

The singular role of a good QE is to be the pessimist.

The singular role of a good QE is the ability to critically evaluate people, process and product.

In effect, the singular role of a good QE is to question and evaluate sources of information.
To question and evaluate risks.
To question and evaluate ideas.

Critical evaluation of information can provide the team with information which allows for a greater understanding of the ‘thing’ being developed which will lead to more informed decisions on the ‘thing’ being developed.

Skilled application of critical thinking doesn’t need to be overt if it is undertaken correctly, it won’t be a visible effect. It will just ‘be’.

A QA has a responsibility to identify, communicate and help in mitigating issues which impact quality, wherever that may lie.

They can coach other specialisations in quality techniques, they can assist in ensuring that the product adheres to ‘quality’ standards, they can inform the team and stakeholders of risks, they can help in providing information on problems that will threaten the value of the software to someone who matters.

History

Socrates was probably the world’s first QA.

He created a method of questioning known as Socratic Questioning.

He promoted a line of questioning that attempted to differentiate beliefs that are reasonable and logical from beliefs that are comforting, egocentric, without adequate evidence or lack a rational foundation to support them.

In 16th Century England Thomas Hobbes adopted a naturalistic view of the world in which everything was to be explained by evidence and reasoning.

The Foundation for Critical Thinking gives a brief definition here:
 ‘Critical thinking is the art of analyzing and evaluating thinking with a view to improving it.’

This ties in neatly with the QA’s expectation of ‘improving the product’…whether a QA improves the product is another discussion for another time.

What it is

Critical thinking takes time and effort to apply correctly.

It is distinctly different from normal, everyday thinking.

In fact, it is the antithesis of normal, everyday thinking.

Everyday thinking happens by default, you just aren’t aware of it, it is a product of repetition and experience.

Walking employs thinking. 
Manoeuvring around obstacles employs thinking. 
Making a drink employs thinking.
Driving a vehicle employs thinking. 
All take place without a targeted, conscious effort.

The advantages of employing critical thinking are numerous. Without employing critical thinking, decisions can be made that can cause adverse effects on your team, and by extension, your product.

Each facet of critical thinking can have a marked effect on your team mindset and the testing efforts employed throughout the development of the product.

It can be employed at any time but in my experience, there is a marked effect when used in group settings such as a daily stand-up, 3 amigos or refinement.

It can, and should, be used when interacting on an individual basis.

Care is needed however to not isolate or otherwise distance the other individual.

This in itself is a skill.

Components of critical thinking

Clarity — Can it be illustrated via examples

Accuracy — Can it be verified

Precision — Is it specific

Relevance — Is the problem in question being addressed

Depth — What makes this a question

Breadth — Are there alternative points of view

Logic — Is this supported by evidence

Significance — Is this the core idea to focus on

Fairness — Are people conscious of their own bias

Or simply, who, what, when, where, why and how ???????????/

How to apply in a context-relevant setting

In my experience, there are two main approaches to conducting a standup.

Your experience may vary.

Critical thinking can, and should, be employed in both approaches:

Standup number 1:
Robotic statements; Yesterday, Today, Blockers, focused on individual contributions.

Standup number 2:
Walking the board; Natural conversation flow, focused on completion of a particular story by the team as a whole.
Getting to done.

The application of critical thinking in the first instance is inherently more difficult as the sequential and individualised format tends to inhibit natural conversational flow. Questioning is directed at an individual for the individual to answer which discourages further interaction(s) at a team level.

The application of critical thinking in the second instance is easier as there is a constant stream of information from multiple sources in real-time, each with a particular viewpoint that can open up more possibilities for questioning and clarification.

At the beginning it may seem quite daunting but the more you employ it the easier it becomes.

There is a distinct and beneficial side-effect of employing critical thinking in that you can articulate your method of questioning to other members of your team.

the more you employ it the easier it becomes

For this reason, the methods will concentrate on a ‘walking the board’ scenario..

‘Over time they will subconsciously adopt these methods in relation to their own statements.’

Real-life scenarios

Let’s run through some typical group scenarios that often occur in cross-functional agile teams:

Developer Jenny states that implementation of the API is almost complete but she believes that it doesn’t require much in the way of testing:

• Ask for reasons for that position

• Are they logical?

• Ask the team whether they agree.

• Does everyone agree with this point?

• Is there anyone who does not agree?

• Query their approach and how they arrived at the conclusion(s) they did

• Is the approach based on fact, supposition or confirmation bias?

Developer George is about to pick up a task to write stubs to support the automation of a particular test effort, he’s done this type of work before and he appears quite comfortable with his approach:

• Ask whether he will undertake research?

• Further information may enhance the implementation, even given his past success

• Ask whether his previous efforts have been consistent with the team’s standards.

• Is this evidenced?

• Can he provide the rationalisation for his confidence?

• Is it well-reasoned?

• Is it logical?

• Ask whether his approach could be improved

• Can team members suggest alternatives?

• Ask if the team can suggest abstract ideas

• There may be underlying assumptions in play

Tester Gwen states that the vehicle selection screen story can now be considered done, BA Bob disagrees.

• Ask Bob why he disagrees

• Can they provide a rational reason for the disagreement?

• Do they have information that isn’t apparent to Gwen?

• Ask whether his disagreement is valid in the context of the story?

• Ask if the tasks that make this story up have been verified

• Can she solicit agreement from the team for her conclusions?

• Does Bob suggest an offline discussion to resolve the differences?

New Developer Alana picks up a task to implement form validation she appears a little unsure on?

• Ask if she can articulate the task within the context of the story?

• Does her understanding reflect the team’s understanding?

• Ask if the card is accurate in intent and accurately reflects the actual task?

• Ask if the the card requires rewording

• Ask the team if Alana’s understanding is correct

• Does the team employ empathy to address any confusion on Alana’s part?

• Articulate your understanding of the problem

• Are there opposing views?

• Are there questions that arise from your understanding?

• Is there agreement from the team?

• Is there information missing that would enhance understanding?

• Is Alana comfortable with speaking in the stand-up

• Is undue influence being applied

You articulate progress you made on a task you completed just before standup, the team appear unsure as to the actual status:

• How do you know that what you’ve done is completed?

• Can you provide alternative phrasing?

• Can you provide an analogy?

• Can you provide evidence?

• Can you ask a colleague to paraphrase your explanation?

PO John queries the status of the sprint as a whole but devolves into a discussion about another sprint

• Question the relevance of the other sprint

• Ask them to reframe the question

• Ask if this is the most important thing to discuss right now

Some takeaways

• Critical thinking takes practice

• No-one thinks critically 100% of the time

• Critical thinking is a tool

• Consciously practice on your own reasoning

• Don’t attempt to inject every type of question into every situation

• Learn to read your team

• Make a conscious effort to observe how individuals respond to different stimuli

• Increase your awareness and understanding of body language

These, combined with critical thinking skills will make you a far more effective quality advocate than any amount of code knowledge.

Introduction

I believe that every single person on a team can test.

I articulate that here:
 Anyone can test
 and here:
 You don’t need QA specialists
 and here:
 Testers are responsible for the quality of the delivered product

That includes any person (on / off a team) that has a responsibility for delivering high-quality software. That person can be a Dev, PO, SM, Designer, Tech writer or a.n other Stakeholder

I’ve had in-depth conversations about what ‘skilled’ testing looks like with all of the above people.

I’m always open-minded when I enter into these conversations, I don’t have the keys to the kingdom.

I’m open to learning.

These conversations (if they happen at all) normally devolve into the throwaway comment. ‘I’ve tested before’ as if that is the silver bullet that tells you all you need to know.

I understand that there are lots of team members and stakeholders that have never seen skilled testing in action before, they’ve never seen the results that skilled testing can deliver so I understand the reasoning and rationale behind the statement.

It gives me a launchpad into the thinking models that they use and what they understand by them, whether they see testing as a dedicated role or whether they see testing as an activity or whether they see testing as something all-encompassing that I haven’t thought of.

Part of our job as testers is to educate and be educated. These are the immediate questions that spring to mind when I hear that comment.

My thoughts

Does it mean ‘I queried the stories for assumptions, ambiguities, correctness and collaborated with the team responsible to remove or clarify my questions’?

Does it mean ‘I adopted a questioning mindset and reported my observations with the appropriate context to the PM / PO / Team / Stakeholder for a decision’?

Does it mean ‘I’ve articulated the risks and collaborated with people to confirm and mitigate those risks’?

Does it mean ‘I’ve found things (explicit or implicit) that may threaten the value of the delivery to the customer’?

Does it mean ‘I’ve followed explicit procedures that I’ve written to the letter’?

Does it mean ‘I’ve followed explicit procedures that someone else has written to the letter’?

Does it mean ‘I’ve demonstrated that it does what it’s supposed to do as per the explicit specs’?

Does it mean ‘I’ve demonstrated that it does what it’s supposed to do as per the implicit specs’?

Does it mean ‘I’m happy to release based on the evidence provided’?

Does it mean that ‘I’m happy that the internal and external expectations have been met’?

Does it mean ‘I’ve written unit tests with usage of the functions in mind’?

Does it mean ‘I’ve experienced the product and I would use it’?

Does it mean ‘I’ve used the product and based on ‘my’ usage model I think it will be a frictionless experience for the user / support team / sales team’?

Does it mean ‘I’ve used the product and based on a ‘defined’ users usage model I think it will be a frictionless experience’?

Does it mean ‘I’ve designed an automated check based on an analysis of criteria that would suggest that the criticality and value of this functionality is worth the effort’?

Does it mean ‘I’ve implemented code using good design patterns such as abstraction, DRY, Solid, POM, Screenplay’?

Does it mean ‘I’ve scripted automated checks based on some arbitrary coverage metric’?

Does it mean ‘I’ve executed automated checks on the understanding that those automated checks will provide a baseline of confidence that a machine can successfully navigate a workflow ‘?

Does it mean ‘I’ve paired up with peers to discuss the value of my activity’?

Does it mean ‘I’ve paired up with peers to identify inconsistencies in my model and my understanding of the product’?

Does it mean ‘I’ve accepted that 100% coverage isn’t possible so I focused on the priority risks’?

Does it mean ‘I’ve adopted a professionally sceptical mindset of both mine and my teams ideas’?

Does it mean ‘I’ve explored and experienced the product with the intent of finding out information about the product’?

Does it mean ‘I’ve found potential issues and discussed / documented those potential issues for investigation by someone who matters’?

Does it mean ‘I’ve evidenced my testing activities to my peers in an articulate, understandable way’?

…and many, many more

Conclusion

There are many more questions that a skilled tester should formulate as part of their approach to advocating for testing as a skilled activity and undertaking testing as a skilled activity….or y’know…js / java / python / framework / auto-magic.

You do you.

Saying that “I’ve tested before” as some kind of golden ticket to skilled testing equivalence doesn’t make it so.

Have the conversations with your team and other people that matter.

It will make you a better tester.

It will make those around you better testers.

It will make your team better at testing.

Introduction

In Part1 here I talked about mentoring.
I talked about the fact that it is a function primarily based on building lasting relationships.

In this post I’ll talk about quality coaching. What I think good looks like, the structure of a coaching session and round it off with a look at the differences and the similarities between mentoring and coaching.

The concepts and attitudes should be in any skilled testers toolkit.

A good tester will, as part of their daily routine, mentor and coach the people around them.

This coaching can be as overt or covert as you like, not everyone wants to stand in front of strangers but paying knowledge forward has no downside.

More importantly, a good leader will assume the role of a mentor and coach as part of their role.

What is a coach?

Coach – ‘A trainer or instructor’

Technical coach – ‘of or relating to or requiring special knowledge to be understood’

A quality coach is a trainer or instructor that has practical skills in the techniques and approaches relating to all things quality.

It’s simple and to the point.
It has other definitions but the ones I use are context specific.

However, as simple and to the point as it is, it doesn’t tell the whole story.
Just as there’s a difference between a tester and a skilled tester, there’s a world of difference between a coach and a skilled coach.

When I think of successful coaches I think of Angelo Dundee, one of the most successful boxing coaches in history. His outstanding characteristics appeared to be his ability to impart knowledge gained from years of experience as a cornerman and bucket-guy and the fact that he was kind.

I think of Alex Ferguson, the former coach of Manchester United. There is no denying the success during his 26 season tenure though it appears to be a drastically different style from Angelo Dundee.
His autocratic style enamoured him to some of his team but equally led to fractured relationships with others.

I think of Ken Carter, immortalised in the 2012 film ‘Coach Carter’. Who chose the more difficult path rather than the most expedient one for his charges.

Each of these relate to sports. The one thing that analysis of these coaching legends tells us is that there doesn’t appear to be a single blueprint for success.

It’s rare that quality coaching gets the same attention or praise.
This is understandable as sport is followed by millions around the world whereas a quality coach may be responsible for a small team that are followed by the members within that team, or on a grander scale, the organisation the coach sits within.

Regardless of size of following, the base principles of being a good quality coach remain the same.

• You want to help others

• Your communication skills are above average

• You have an in-depth knowledge of the subject matter

• You can actively listen

3 guiding principles to be a quality coach (or what works for me)

A helper mindset

This is the singular most important attribute a good quality coach can possess. Genuine enthusiasm is hard to fake.

People remember good teachers, they remember the enthusiasm, the empathy, the patience.

People respond to this way of teaching. You have to genuinely want to help others succeed.

This is especially true in the field of quality coaching.

A field that can be unbearably dry and one that is dry by design.

A quality coach has an ability to go from micro (small, individual sessions) to the macro (whole team sessions).

They will create and run workshops.

They undertake 1-2-1 coaching.

They may analyse current processes and advise on improvements.

They will undertake hands-on sessions.

Technical in the software development space doesn’t just mean hard skills.

A large element of being a technical coach involves people skills.

People are complex machines with needs, wants and opinions of their own.

A good coach will be adept at communication in all it’s varied forms.

A good communicator

Many, many people have an in-depth knowledge of their particular fields.

I’ve worked with developers who have brains the size of small planets but this is sadly not matched by their communication skills.

A good coach will be adept at communication in all it’s varied forms.

They have active listening skills, they are empathetic, they use critical thinking to frame appropriate questions at appropriate times, they understand inbuilt bias and they are patient.

A good coach will spend most of their time listening.

A good coach is comfortable in silence.

As a good coach, it’s fundamental that you are able to frame and communicate concepts in an understandable manner.

Be aware that, even though by virtue of being a coach, there will be situations where you will find yourself thinking on the spot.

The manner in which you respond to questions that you can’t answer is every bit as useful as seamlessly imparting your knowledge onto the participants.

It pays to have an awareness that coaching a testing technique or approach to a group of testers will result in open-ended questions.

Good testers are curious by their very nature.

Encourage this, even if it isn’t the primary focus of the session.

Subject Matter Knowledge

Simply having x years experience in a particular subject doesn’t make you a coach.

It does however, make you a candidate to become a coach.

There is so much more to coaching than subject matter expertise though it is the absolute fundamental building block to be able to move forward.

All the organisational, slick presentation skills in the world won’t make you a good coach without a sound baseline understanding of the underlying subject matter.

As your career progresses you may find yourself becoming the go-to person for queries related to a particular subject or domain.
This is a good thing.
People already consider you to be an SME for that subject.

Even though you think you know your stuff, you need to take a learning mindset into each session.

No two sessions should ever be the same.

The participants, the environment, the subject matter may feel exactly the same but in reality, each will have subtleties that affect how you coach.

Structuring a coaching session

If you find yourself answering the same queries repeatedly now would be a good time to consider the creation of a workshop to disseminate this learning.

This isn’t a throwaway task, well crafted workshops can take months to prepare.

Articulating what you know into a format for teaching, in a pre-determined amount of time, to an as-yet, unknown audience can feel like a daunting task.

My first workshop was created as a result of discussions where I would answer the same queries over and over again in an isolated 1-2-1 manner.

Being naturally gregarious I started to think of ways in which I could show this en-masse to a ‘semi’ captive audience.

I researched online, read many, many articles.
I used experiences from being the attendee at numerous workshops, both the good and especially the bad.

I wanted to spread the knowledge, I’ve never adhered to the ‘knowledge is power’ mantra that seems to afflict some others.

If I know it, and it’s been useful, why not share it and allow your organisation to benefit.

I created a seven minute lightning talk, not earth-shattering by any means but enough to convince me that:

• I knew my subject matter

• I could distil ‘what‘ I knew into meaningful chunks

• I could have a positive impact on other peoples knowledge, skillset and learning

The models

I came across two models that I used to guide me in preparing coaching sessions. I’m sure there are more but these have seemed to fulfil my needs.

FUEL – A conversation framework

GROW – A behaviour based model

I prefer FUEL as that appears to be more aimed at behavioural outcomes though I use elements of GROW to set my goals and objectives;

Rather than dissect what each does, here’s a handy link where they are broken down and compared.

My model is broken down into:

• Setting the stage

• Layered Learning

• Small chunks

• Visuals trump text

• Check understanding

• Repeat

Setting the stage

It’s one thing to promote the purpose of a workshop in a loosely worded email.

You may even have marketing literature that promotes your workshop.

It’s another when you’re stood in front of a group of people eagerly awaiting for you to open the magic box and guide them along the path to enlightenment in the chosen subject.

Make the first few minutes of your workshop count.

Communicate exactly what the participants will get out of this.

Saying “We’ll explore example mapping, we’ll create concrete examples, maybe of real features you’re developing, we’ll turn those concrete examples into acceptance criteria, we’ll use the Gherkin DSL to create scenarios, we’ll talk about the impacts of collaboration to ensure a shared understanding.
We’ll learn what good looks like.
We’ll discuss the different approaches and how you can affect the outcomes of discussions…..etc…” sounds far better than
‘This is about BDD’

Saying “When you leave this room you’ll be able to more effectively contribute towards the testing effort because you will understand the principles of ‘x’ to apply and when to apply them. You’ll become the coaches.” sounds far better than
‘You’ll know BDD’

Communicating the context of the session is a must.
How you achieve this is entirely up to you and your particular style.

Set the stage, create the expectations

Regardless of the pre-requisites you wish to place on attendees, I can guarantee that attendees will turn up with various levels of experience around the subject matter.

You may have participants that satisfy the pre-requisites that in actuality, don’t understand the fundamentals of the subject matter at hand.

Your job as a coach is to be aware that there is potential for this.

The participants may think they understand the base concepts but as with most human-oriented learning, ego, and the presence of their peers, will compel them to not admit to a level of ignorance.

This can lead to problems that will only increase as the material is taught (assuming that each concept is layered on top of the previous one).

It can ultimately lead to dissatisfaction with the course itself, participants with unfulfilled expectations and by extension, your reputation as a coach.

Every time I run a workshop I make an absolute mental note to discover the participants existing knowledge.

I use a simple solution, though it is by no means fool-proof.

I ask the participants to write a number on a post-it that summarises how comfortable they feel with the subject matter.

I scale this 0-10 with a qualifying statement for the two extremes.

This post-it is placed in a visible position in the room and is revisited at the completion of the workshop.

I make a note of the participant scores.

I’ll then ease into the subject by asking a generic question of each participant with an internal emphasis on those who scored themselves above a 5.

The answers enable me to gauge exactly where they really are as opposed to where they think they are.

This isn’t structured to embarrass or highlight their knowledge (or lack of).

The point is to know the speed I can progress at whilst ensuring that no-one gets left behind.

I’ve been a participant in many workshops where there was an assumption that participants had the pre-requisite working knowledge to gain effective learning from the subject matter.

I’ve been left behind in workshops where I wasn’t familiar with the intricacies of a particular IDE (as that what was the instructor was using to demonstrate the concepts)
It doesn’t make for a particularly pleasant experience to be constantly asking for help whilst simultaneously being aware that you are, in effect, holding the progress of the workshop up.

At no time during this particular workshop did the instructor stop for a moment and reflect on the fact that I had a different amount of experience with their IDE so maybe some extra time to complete / otherwise assist a particular exercise would have been warranted….also asking for a volunteer/buddy to assist would have made a huge difference.

There is an absolute difference between what you think you know and what you do know.

Layer the learning

Logically splitting the subject matter into small chunks seems to work for me.
It enables me to focus on a small amount of information at each stage.

This is then expanded upon in subsequent sections.

At the end of each section I try to recap how this fits into the bigger picture, i.e how using the principles of BDD contributes to a shared understanding within the wider development lifecycle.

Logically split the subject matter into easily digestible pieces

“A journey of a thousand miles begins with a single step” is a common saying thought to have originated from the Tao Te Ching.

It’s as valid now as it was back then.

Separate the subject matter into easily digestible chunks.

A process known as chunking.

I use this in conjunction with the layered learning concept to optimise information understanding and retention.

You can chunk-up (micro to the macro) or chunk-down (macro to micro) dependent on the participants interaction.

Present the information at a level of detail that is sufficient for your audience.
The amount of detail can be varied in real-time depending on them.

One method of knowing when to shift gears is to ask questions during the workshop.

These questions should be targeted around the concepts that are being taught, they should promote creative thinking in the participants.

They should be open-ended.

Small exercises are useful, I tend to stay away from individually focused exercises, we don’t develop software in a vacuum, why should learning in a group setting be any different?

Use visuals

A picture tells a thousand words.
I use a lot of visuals to communicate concepts and ideas.

I support these visuals with bite-size text to help illustrate the concept

A succession of slides presented in a robotic manner with the ‘coach’ simply reading off each successive bullet point does not make a workshop.

It makes for a very tedious couple of hours.

Short bullet points are fine as long as they are used as a jumping-off point for an explanation of the concepts under instruction.

Death by Powerpoint is a very real thing

Check understanding

This is a hold-over from my military service though I have no doubt it is taught elsewhere.

At the conclusion of a briefing or ops group the briefer would go around the audience and ask members to paraphrase the instructions or orders given to that point.

This would have the benefit of ensuring that the recipients understood the contents and allow the other participants to gauge or otherwise modify their understanding.

The concept is relatively simple:

At the end of a section, ask the participants to summarise their understanding of the information that has been presented to them.

Be aware that individuals have differing levels of communication so a reactive style of question based around a practical application works well, even better if you can place the question in the context of how they work at the time

Differences between a mentor and a coach

A mentor is primarily a relationship game.
A mentor is a long-term commitment.
A mentor doesn’t have to be a subject matter expert.
A mentor can use elements of coaching in their approach.
A mentor will aim at developing the person

A coach is primarily an information provider with a human touch.
A coach builds short-term relationships, however, short-term does not mean transient.
A coach needs to be a subject matter expert.
A coach provides targeted teaching in a specific timeframe for a specific goal.
A good coach will leave people and processes better than they found them.

Conclusion

Once you have gained a certain level of knowledge it appears to be a natural progression to becoming a coach in that particular area if you feel that you can add value in the subject area.

A good coach will be remembered long after the workshop ends.

Coaching doesn’t have to define you, you can informally coach in a small capacity; think lightning talks and brown-bag sessions.

Not everyone wants to be Tony Robbins.

If you’re a tester in a position of authority I think you have a responsibility to coach those around you to be better at what they do, regardless of their specialisation.

You can *follow me on bluesky where I maybe-sort-of post presumed nuggets of learned QA wisdom.

*post Space-Karen acquisition of Twitter

Introduction

The line between mentor and coach has always seemed a bit blurry to me.

You will mentor because you have life experience that you can pay forward.

I would class this as life-coaching without the extraneous ‘right-on’ baggage.

It may not actually matter to you that there’s a difference.
 
Truth-be-told, it’s never bothered me but it’s been an interesting thought experiment to delineate what I think each role comprises of within my context and my experience.

In this first part I’ll look at what I think constitutes good mentoring and provide an outline of what has worked for me, along with some examples.

In the second part I’ll explain what I think makes for a good coach along with the key differences between the two.

Part 2 here

TLDR;

My take is that mentoring helps build a person, both personally and professionally in their role and their attitudes, it’s not timeboxed and has no formal rules.

I see coaching as much more short-term. 

Coaching is targeted teaching for a particular skill-set based on a particular skill-set that you (as the coach) are highly proficient in.

Definitions

As with my testing approach, I like to have a consistent baseline to avoid confusion when terms are referenced.

This is what the Collins English Dictionary has to say:

Mentor — ‘A person’s mentor is someone who gives them help and advice over a period of time, especially help and advice related to their job.’

Coach — ‘A trainer or instructor’

Nice and succinct.

I like these.

The Mentor

Mentoring is a relationship….and like most relationships, there will be highs and there will be lows. No relationship is perfect.

The mentor models

These are the mentoring models that I’m aware of. There are probably many more:

The proxy mentor

There’s a school of thought that anyone in a leadership role is a mentor by default. 
I take this quite seriously.

A good leader will inspire by default, whether overtly or covertly.

The difference between this and the other models is that this mentoring doesn’t take place on a one to one basis but is mentoring by osmosis.
 
The words and actions of a good leader will have a marked effect across the aspirations of whole teams.

The accidental mentor:
I think I’ve stumbled into mentorship just by virtue of the role I’ve been engaged in.
 
In hindsight, it appears that I’ve implicitly accepted that by virtue of wanting to help people succeed I automatically adopt a mentoring mindset.

There’s a school of thought that states that you have to be explicitly asked to mentor, I’m not sure that holds true, though it may have value for introverts.

The mentoring program: 
My preferred model is a mentoring program where there are a pool of volunteer mentors.
 
They have demonstrated the attributes to become a successful mentor.

They have the right temperament, attitude and communication skills and crucially, they have a genuine desire to want to help others.

Their availability as mentors is promoted org-wide and people can contact them to discuss expectations.
 
I really like this model, it leads to natural pairings that evolve organically.

The formal mentor:
I’ve also been involved in orgs where the mentor program is more formal in that you are assigned a mentee, this always seemed like thinly disguised people management.
 
I’ve been wary of these types of relationships.
 
I think that relationships are at the heart of mentoring.
 
Any situation in which you force people to engage without a baseline of common ground and shared values will be strained at best and fractured at worst.

That isn’t to say that the programs a lot of companies seem to adopt don’t work, they may do, but they’ve always left me wondering whether it’s an artificial success.

My mentoring journey

My most memorable mentor was a gruff, no-nonsense Irishman.

In hindsight, he was as anti-me as I could think of.

When I made mistakes there was no quiet chat, no coffee to discuss what I could have done better. 

It was a case of ‘let’s do it better’.

He cared about the craft of quality, he was very aware that what we produced as deliverables could have very real effects on very real people.

He also had a knack of cutting through the noise.

Did he make me a better person? Absolutely.

Did he make me a better tester? Absolutely. I owe him a lot.

Would I have responded with another approach? 

Maybe, but in hindsight, it was the best approach for me at the time.

Given my experience now I can point out many departures from my guidelines…but it worked for me at the time I needed it.

So, on the off-chance that he stumbles across this blog, thanks Andy.

Off the top of my head I can think of 20+ people I’ve mentored.

Of that number maybe 10 have been peers (other QE), the rest have been devs/BA’s or UX.
 
I’ve always been a firm believer that mentoring can occur outside of a speciality.

I’ve mentored seasoned devs who thought that testers were impediments to delivery.

 I’ve mentored devs who approached each problem with a code-first mindset.

 I’ve also mentored devs who knew a lot about a little.

I’ve mentored graduates who were in the first flush of working in a development team who brought a natural enthusiasm along with a healthy scepticism towards quality. 

They brought ideas (direct from a closeted learning environment) that didn’t really align with the ideas and practices of a modern quality approach.

Importantly, I mentored to open up the individuals way of approaching their thinking.
 
This may have had an indirect effect on their perception of quality but it wasn’t the primary motivation.

I enjoyed all those experiences, we can get so wrapped up in what we think we know that it’s very easy to forget that what we don’t know is far more important.

I’ve mentored junior, peer and senior roles, there is no rule that says that you can only mentor those below you in the career ladder.

The value in you as a mentor is your experience, life or otherwise, that you can impart to your mentees.

What mentoring means to me

There are particular guidelines I’ve developed as my experience has grown.

I made a lot of mistakes early on in how I interacted with the mentees. 

Chief amongst them?

I learnt pretty quickly that I wasn’t their surrogate parent.

Each experience is different, each person is different, but there are absolutes I follow that will never change regardless of the person I mentor.

This appears to be quite an exhaustive list but it isn’t a roadmap.

They are observations and actions that I’ve found that have helped me to cultivate lasting relationships.

Respect the individual: The goal is not to create a mini-me, the goal is to help the individual become a better version of themselves

Listen more than you talk: You may need to temper your natural instinct.
It’s less about asking questions than it is about framing the right questions based on their experiences

Ask the right questions: The most important questions you can ask as a mentor are ‘What do you think?’ or ‘What do you think happens if you do this?’

Make it natural: Encourage people, don’t force them to comply

Not multiple choice: Don’t treat it like a tick-box exercise

It’s not about you:
The purpose is to lift the veil of uncertainty which is a long-winded way of saying ‘help them understand the art of the possible’

Check their understanding of any key principles, have they acted upon your advice?
 
Have they arrived at a conclusion that is different to your advice?

Does their current thinking differ from your perspective?

This is incredibly valuable as it shows they are growing as an individual and as a person

It’s not all sunshine and rainbows:
Don’t be afraid of having difficult conversations. 

Part of what you offer is the ability to diplomatically provide feedback.

It’s not just about sunshine and rainbows.

You won’t be effective if you only ever praise.

That path will lead to ruin, both for your capabilities and your mentees confidence

Create a structure:
Agree how you’ll do it.
This is a joint conversation. 

Agree on a structure, determine how they like to be interacted with, ensure that they understand the structure. 

Let them choose what they focus on, have a kick-off meeting where you actively listen to what they perceive to be their wants and needs. 

Agree on how they like to receive communication. 

It may be that they work in a different part of the building, although F2F is the most effective method, the approach needs to be determined in conjunction with the mentee

Short term goals:
A mentor relationship is long-term but the goals should be short-term, set achievable, small, victories.

Build their teaching skills:
Part of the remit is to create the leaders of tomorrow.
Even if that isn’t their primary focus or natural fit, expanding a teaching skill-set will create lots of transferable skills

Regularly review progress:
Whether you meet up for a coffee once a week or once a month, set up a regular session to review progress

Agree end-goals:
This means agreeing on short-term improvements that directly contribute to their long-term goals.
Know how to recognise when you’ve reached the end of a particular learning opportunity

Be kind:
You are a mentor by virtue of your experience, knowledge and communication.
 
This does not grant you omnipotence. 

Even if your gold-plated advice seems the only way forward, don’t dig your heels in.
 
It’s advice, not a commandment

Own your mistakes:
You are human, you will make mistakes.
Use these mistakes to further the relationship with the mentee. 

Don’t fall into the trap of thinking you have all the answers.

That’s not how the world works.
 
You will run into tricky situations that you aren’t best placed to deal with.
 
Be confident with your mentee, admit that you need to seek advice in dealing with it.
 
This shows that you are human and exposes a vulnerability to the mentee that will improve the relationship

It’s not sideways micro-management:
Micro-management in any form is a hideous leadership style.
 
A mentor will not attempt to manage in any capacity

Be aware:
Look out for the person you mentor.
If they crop up in conversations, how are they perceived? 

Have an awareness of the other personalities that make up their immediate eco-system. 

Be aware of the dynamic that exists.
 
By the very fact that you have experience that exceeds the mentee you need to take care that you don’t create a paralysing situation, you want this person to take advice. 

A simple ‘hi’ at the coffee station will help in creating a natural flow.

You don’t want to end up in a stilted relationship.
 
You aren’t a superhero

Know yourself:
Carry out regular introspectives on yourself. 
Are you still the best person to continue their growth, is there someone better placed to continue their education.

Don’t be precious about relinquishing the reins. 

It’s not a slight on yourself to admit that they’ve outgrown you.

If anything, it’s a huge compliment that you’ve contributed to that person becoming who they are and they are ready for the next phase.

Be aware, and proud, that you’ve created a lasting relationship

Examples:

Experiences help people grow.

Someone wants to gain confidence in public speaking.
 
An experience to meet this goal could be presenting a 99-second talk to you, then their immediate peers, then QA + Devs.

The next step is a lightning talk of 7 minutes long….and so on and so forth.

They could aim to ask at least 5 questions in a standup or a refinement, then 6 questions.

 It’s measurable and has mini-goals.

They could have an objective of introducing themselves to at least one new person at the org per week, either in person or via a message.

It doesn’t need to be a forced oratory, a simple, ‘Hi, I’m x, I work in x, I’m improving my communication skills / increasing my confidence, I’d like to find out more about what you do?’.

This works for introverts.

They may want to improve their critical thinking skills for the inevitable ‘testing is a bottle-neck’ conversations.
 
You could recommend reading or an online course.

Their critical thinking faculties may short-circuit as a result of stress.

You could advise on relaxation techniques.

Longer term you could ask them to informally debate you, with you acting as a devils advocate.

Conclusion

A good mentor will be remembered long after the mentoring period has finished.

Good mentoring is difficult but ultimately very rewarding.
Mentoring can occur outside your specialisation.
Mentoring can, and will, use elements of coaching.
Mentoring is not an opportunity to create a mini-me.

A good mentor will take the time to get to know the person.
A good mentor can read the mentee.
A good mentor will understand the weaknesses of the mentee.
A good mentor will challenge the mentee.
A good mentor is always open to be challenged.
A good mentor will be remembered long after the mentoring period has ended.

You can *follow me on bluesky where I maybe-sort-of post presumed nuggets of learned QA wisdom.

*post Space-Karen acquisition of Twitter