Quality Coach: a team approach to mapping "the work"

There are many habits that 'high-performing teams' exercise to deliver high-quality products. Twitter, the ultimate truth teller of all topics, gave me this when I asked the question. So I kickstarted the question with these ideas:

Apologies if I missed your contribution; Twitter can be a beast with its replies.

Today, I'm doing a deep dive into early and frequent feedback as a way to improve overall product quality.

In my experience, early and frequent feedback built on a shared understanding of what good looks like can massively impact the quality of what you deliver. Teams that build in early & regular feedback loops maintain alignment right to release. Not only are they more confident about the product as a whole, but they're also less stressed as typically they have "no surprises" releases. There's nothing like a problem discovered before or after deployment to raise your blood pressure!

In its essence, software testing is a method of feedback. If performed in isolation, software testing gives you valuable feedback on your work. However, if it's performed with another, it takes that value up a notch. Just like input to one test is useful, and multiple inputs offer better coverage, so does testing with more than one person (oracle) make your testing more robust. And there are a host of other benefits; it builds domain knowledge, develops shared understanding, and develops teamwork and empathy for others' work.

Of course, not all work can or should be done in collaboration. There is value in time for self-reflection and independent work. More and more, though, software development is becoming a team activity and working as a team becomes essential to a successful outcome. Perhaps the ideal sweet spot is to identify optimal moments in the delivery workflow to develop a shared understanding and to check the team continues to be aligned. Testing can be an optimal time to validate that you are satisfied with the work and that your team is confident with the outcome.

The workshop I'm describing below helps teams identify ways to inject moments of shared understanding and paired testing into a team's delivery process.

Mapping the Delivery Workflow

An excellent place to start is to ask the team to map out their existing delivery workflow.

Mapping out your delivery process is helpful for the whole team to understand where they do their software testing and how they collaborate. In addition, mapping this out gives you the starting point to discuss where and what the team can improve.

Delivery Workflow Workshop

Preparation

Preparation is key in this workshop. You want to identify if this workshop might be helpful to the team at this point. No matter how motivated, stressed teams will find it hard to devote headspace to continuous improvement. I suggest the following;

• Talk to delivery leads and tech leads. Would this workshop be something of value to the team? Is it a good time to run such an exercise? Getting buy-in from tech leads and delivery leads means that the workshop outcomes are more likely to be acted on.
• A great book on this topic is "making work visible" by Dominica Degrandis
• Create an online board based on the delivery workflow workshop Miro Template and share this link in the invite.
• Work through your timings and the questions you want to ask. The questions frame the discussion, so think carefully about what you want to ask.

You will need the following:

1. Online Miro Template
2. Book 2 x 45 minutes sessions or 1 x 90-minute session with the whole team
3. Provide an overview to the team at least two weeks in advance, outlining the workshop's purpose, the personal benefit, the outcome, and the process used.

Workflow Mapping  Session One  

The first part of the workshop aims to identify the team's different workflows and ways of working.

1. Ask each team member to map their workflow process for the agreed iteration/sprint.
2. Using an agreed coloured dot, ask them to identify where the testing work is done.
3. In the same way, ask them to identify tasks that have work done separately, done in pairs, and done as a team.
4. Have each member talk through their process and explain their thoughts and motivations around the process
5. As a group, identify similarities and differences between the processes and encourage comment and reflection.  

I prefer to split them to allow the team time to reflect on what they've observed and learned from each.

I like to end the first session here, but there's no reason you can't blend the two sessions into one and keep going onto session two.

Facilitator Role: As a quality coach, your role is to facilitate this discussion and, once the session is complete, tidy and ready the board for session two. Collate similarities, highlight differences, capture observations, suggestions and thoughts and share before the next session.

Workflow Mapping: Session Two

Time to identify and action improvements. Think ahead about where opportunities might exist. If the team becomes stuck, you can suggest some ideas. For example, based on the discussion you heard, think about;

• Opportunities to create a shared understanding of the work and its associated risks. Think card elaboration, risk storming and card kickoffs.  
• Opportunities to receive feedback on work as early as possible. Think pairing and shoulder checks, especially between different specialities.  
• Social contracts that the team agrees to on quality. Definitions of done, principles of clean code etc.  
• Opportunities to reflect and continuously improve.  

Session Two

The Keep, Stop, Start pattern is useful to help identify specific activities that cover shared understanding and testing.

Looking at the new workflow, ask the team:  

1. What is helping our quality that we want to keep doing?
2. What is preventing us from doing quality well that we should stop doing?
3. What are new quality-related activities things we want to experiment with doing?

For option 3, frame any new idea as an option or an experiment. Again, no one is setting these ideas down in concrete as must be done. Instead, these are options that a team can experiment with.  

Here's a possible list of options. The team may supply other options and suggestions; add those to your list.

• Card Elaboration (do we understand the scope of work and what it means?)
• Card Kickoffs to identify agreed acceptance tests
• Shared review of the definition of done at completion. (have we done what we said we would do)
• RiskStorming sessions at the start of the Epic to identify threats to business value
• Whole Team Testing Strategy
• Paired testing sessions between roles. For example, Designer & Front-End time boxed paired session, front-end & back-end paired session on integration tests.  
• Group Exploratory Testing Session
• Accessibility & Usability Testing Sessions
• Missing test automation suites
• Retrospective on testing to identify what went well and what we could do better next time.
• Shoulder checks to validate testing scope.
• Pairing at handover points to check for alignment
• Card Elaboration Workshops to generate shared understanding
• API Test Automation (Pact)
• Agree to a 10% allocation to quality improvement
• Stop picking up new stories off the backlog until all of the team do the previous story.
• Introduce, revisit the definition of done at story completion, at epic completion

Finalising the roadmap

Time permitting, prioritise the ideas based on impact and effort. Then ask the team to vote on what cards they want to begin with first. Next, focus on the top 1 or 2 ideas and suggest working on these.

For each idea, emphasise the experimental nature of the concept and that based on feedback, we can discontinue or tweak or come up with a new idea once there is some data available.

What is essential is that the team takes the first small step to move that card forward. Create cards, identify appropriate ownership and add to the team backlog.

If you have an iteration manager or delivery lead on the team, work with them to ensure the cards are being addressed and delivered.

Implementing change within the team.

How well you work with the team's iteration manager or delivery lead often determines if this work gets implemented. Talk to them before this workshop and gain some consensus that they will work to implement any outcomes from the workshop.

Working with the practice delivery leads to continuous improvement, and building quality into the process is an excellent way of consolidating ideas and ensuring their success.

If this option is unavailable to you, ask to attend retros and/or arrange continuous health check catchups with the team to discuss how it's going. Again, be open and flexible to tweaking ideas or reducing the complexity of suggestions.

A comment on the "flow of work."

This workshop focused on a delivery workflow with a diverse cross-functional team. Technical teams with similar roles may find that reviewing a GitHub process or deployment pipeline is a more suitable exercise.