Quality Coach: a team approach to mapping "the work"
Today, I'm doing a deep dive into early and frequent feedback as a way to improve overall product quality.
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:
my thoughts so far:
— Anne-Marie Charrett | Quality Coach Book | (@charrett) August 28, 2022
They consistently look for ways to develop a shared understanding
They test early and often using techniques such as pairing, and shoulder checks
They lean to small & frequent delivery of value to production
Frequent retros, small experiments, sticking to working agreements
— lisacrispin (@lisacrispin) August 29, 2022
Honest conversations
— Craig Wylie (@TheWylieKyote) August 29, 2022
They have a strong sense of shared responsibility for delivery
— tobyhede (@tobyhede) August 28, 2022
- Quality-minded senior developers
— Areti Panou (@unremarkableQA) August 29, 2022
- Code base with few dependencies
- Teams owning code to production cycle
- Product management allowing time for testing and maintainance
Longer version here 😁https://t.co/XMwRAEXlYX
They focus on:
— Sponge Bob Test Pants (@RobMeaney) August 29, 2022
- Delivering as a whole team
- Slicing as small as possible(smaller than most think possible)
- Outcomes not output
- Progress over perfection
- Experimenting continuously based on whole team reflection
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.
