Quality coaching refers to a bottom-up approach to quality improvement in software teams in which methods such as three-amigos sessions, risk storming or communities of practice are used in a targeted manner to enable teams to help themselves. The aim is not to impose solutions from outside, but to transfer knowledge to the team until external support is no longer needed.
Key Takeaways
- Quality coaching differs from traditional consulting in that it takes a bottom-up approach: interviews with the team uncover the actual cause of the problem, not just the symptom named by management.
- The three-amigos method, in which requirements, development and testing think through a user story together, significantly reduces discussion points during refinement because everyone understands in advance what the acceptance criteria are.
- The greatest coaching success is achieved when the customer applies the methods learned independently and no longer needs the coach.
- Communities of Practice need a dedicated moderator at the beginning to get them up and running; the two-week interval gives participants enough time to prepare and ensures a stable rhythm.
- Regardless of the process model, whether CI/CD, waterfall or agile, test environments are a permanent problem area in which a disproportionate amount of time and money is lost.
What distinguishes quality coaching from traditional consulting
Quality coaching starts at the bottom, not at the top. Instead of bringing a ready-made solution to the project, a quality coach works with the team on the cause of the problem and enables people to apply methods themselves.
The difference is in the approach. Many consultants bring a fixed approach that they roll out at a certain point. Coaching takes the opposite approach, using interviews and direct contact with the team working on the project on a daily basis.
This proximity brings to light information that is missing from the management picture. Bastian Baumgartner describes a case in which a customer combined all test managers, test automation specialists and testers under one title. Real job anxiety arose during the interviews because people didn’t know whether their skills matched the new role.
The benchmark for good consulting is clear.
The greatest success of consultants is when clients no longer need us. When we have managed to enable them to implement the methods themselves.
Bastian Baumgartner
Why knowledge often does not reach the team
A common pattern in agile transformations: Management is given a quality coach, but the knowledge is not passed on. Problems only arise during testing, and then consultants are brought in.
This is exactly where you quickly slip into the coaching role. You show methods that the management may have known for a long time, but which have never reached the team. Small methods can have a big impact at this point.
Three amigos: Clarity before refinement
Three Amigos is a method in which three disciplines discuss a user story before the team goes into refinement. The name refers to the disciplines, not the number of people at the table.
The participants are the requirements side, often a product owner or a technical PO, development and testing. Together, they clarify how the story can be implemented and how it can be tested. A separation into technical and functional tests is common.
The effect becomes apparent later. If it is clear to everyone what is to happen with the story and how the acceptance criteria are to be achieved, the long discussions in the refinement phase are no longer necessary. One customer initially doubted the extra three quarters of an hour, but then saw how much faster the team got all the stories estimated and finished.
The method kit for getting the team started
Quality coaches work with a toolbox of methods from which they choose to suit the client. They usually start with interviews because they provide the best overview of where the problem really lies.
The results of the interviews are anonymized and bundled into clusters. Further work is derived from the top 3 or top 5 topics. This is often followed by a discovery workshop, the form of which depends on the client’s organizational structure.
Some proven formats from practice:
- Pains and Gains: The participants write the three biggest pain points in the test process and the three most effective fields of action on post-its, which are put on the wall and become clusters.
- Risk Storming: Provides a good basis for developing a test strategy, for example.
- Find-the-Bug-Sessions: A joint exploratory testing so that people can see how this can work.
- Testing tours: Structured exploratory approaches for practical use.
- Testing for Non-Testers: Foundations for roles outside of testing, such as a Scrum Master to be trained more towards testing impediments.
The recurring pains: test environments and skill-up
Some problems occur regardless of the process model. Whether CI/CD, Water Scrum or other: test environments cost a lot of time and money everywhere.
Good management of test environments is therefore a separate chapter in the Quality Minds test master training program. Our work with customers has resulted in best practices that also contribute to release management.
The second perennial issue is the skill-up of testers. In agile teams, testers are expected to have automation skills. This does not mean that everyone has to program Java. A lot can be controlled using the right toolset.
Best practices of others are best practices of others
In practice, agile frameworks are never implemented one-to-one according to the textbook. Nobody runs Scrum, Scrum of Scrums, LeSS or SAFe 100 percent according to the template. It is always adapted.
Even the Spotify model only worked up to a certain point. When the company became too big, it no longer ran smoothly, even though the name was on it.
This leads to practical advice for teams: you can pick out the good parts and use them. You don’t have to adopt a framework completely. The framework behind it doesn’t matter at first, it’s about helping people solve their problems.
One point of criticism remains with scaling frameworks: the test is often completely left out.
Why the mindset change is the biggest challenge
The biggest hurdle in coaching is not the method, but the mindset change. It is particularly difficult in companies with clear hierarchies and fixed structures.
The expectation is often that you will switch to Agile software development from one financial year to the next and that all employees will follow suit. This does not work without support. Many people have worked in an organization for 15 or 20 years.
Testers find it particularly difficult to organize themselves. For years, test managers pushed the tickets to them before the sprint. Now they are expected to pick up tasks themselves and take on responsibility. This change takes time.
Community of practice: how the mindset is really changing
A community of practice is an organized association on a subject area that ideally manages and organizes itself. This is exactly where you can observe how the mindset changes over time.
For customers, for example, a community of practice for testers was set up with pre-agreed topics. The focus is on sharing experiences: anyone who has successfully used a new tool or method presents it. This promotes mutual learning. Internally at Quality Minds, this takes place every two weeks in a format called “Let’s Test”.
A two-week cycle has proven its worth. It leaves enough time for preparation, research or comparisons, and still keeps the community moving. If interests diverge too widely, a community can split, for example into a separate strand for test automation.
A newly established format does not run on its own. Initially, it needs a moderator or community manager to provide guidance and keep it going until the whole thing is self-sustaining. Sometimes it even needs the approval of superiors so that the participants can invest three quarters of an hour every two weeks.
Quality is created in the team, not in testing
Quality is the result of the overall process. You can’t test quality into a product at the end, so the whole team has to be involved, not just the testers.
The tester traditionally sits at the end of the food chain. Mob testing sessions bring everyone together earlier. In a driver-navigator approach, one person sits at the front and tests, while the others take it in turns for two minutes each to determine how to test.
The learning effect arises from the different perspectives. The team sees how a developer approaches the matter and how a software architect does. This exchange of knowledge is the whole-team approach in practice.
Resentment against testing is less common today. Agility has brought developers and testers closer together, and the former divide has become much smaller. Developers see the added value when testers get a technical skill-up and both learn from each other during automation.
Where the greatest potential lies: End-to-end and AI
Two topics are shaping the next phase of quality work: end-to-end testing and AI.
End-to-end testing lacks an established methodology. There are numerous tools, but no best practices to build on. As long as teams stay in their own application and their own services, they have everything under control. As soon as things move towards system integration, there is confusion and wrangling over who organizes what.
The problem is exacerbated where there is a lot of technical specificity in the test cases. Then people from the specialist department are involved in UI-driven testing, which ties up resources and creates long test activities. Passing the baton at the interfaces is mediocre, and a discovered problem can sometimes slow down the team for two days. This is exacerbated by the fact that more and more companies are building software to produce another product, such as a car, and are correspondingly shirt-sleeved.
When it comes to AI, opinions differ on one distinction: am I testing with AI or am I testing AI? These are two different worlds, and both require their own methods. The approach is changing fundamentally because the quality criteria are different. In the past, tests were carried out deterministically against fixed criteria. This is precisely the point that is shifting, and quality coaches are called upon to develop new approaches.
Frequently Asked Questions
How can you tell if quality coaching has really been effective?
The benchmark is the point at which the team no longer needs the coach and applies the methods independently. Quality coaching therefore doesn’t rely on a pre-packaged solution that’s rolled out all at once, but rather on interviews and direct contact with the people working on the project every day. Empowerment is the goal, not a constant presence.
Why isn’t it enough to train management on quality issues?
Because the knowledge often stops there. A common pattern in agile transformations: Management gets a quality coach, but the team doesn’t hear a thing about it. Problems then surface during testing, and consultants are brought in to present methods that management was already familiar with. It is precisely in this gap that small methods have a big impact.
What are the benefits of jointly working through a user story—covering requirements, development, and testing?
It eliminates lengthy discussions during refinement. If it’s clarified in advance how the story will be implemented and tested, and how the acceptance criteria will be met, the team can get through the estimation faster. One client was initially skeptical about the extra three-quarter-hour but then saw how much sooner all the stories were estimated and completed.
What quality issues arise regardless of the development methodology?
Test environments and tester skill development. Whether CI/CD, waterfall, agile, or Water Scrum: Test environments take a disproportionate amount of time and money everywhere, which is why managing them deserves its own chapter on training. In agile teams, testers are also expected to have automation skills. That doesn’t mean everyone has to program in Java; much of it can be controlled via the toolset.
Does a team have to adopt an agile framework completely by the book?
No. No one follows Scrum, Scrum of Scrums, LeSS, or SAFe 100 percent according to the template; it’s always adapted. Even the Spotify model only worked up to a certain company size. You can pick and choose the best parts. When it comes to scaling frameworks, there’s one persistent criticism anyway: testing is often completely left out.
What does a community of practice need to keep from fizzling out after a short time?
Initially, a moderator or community manager who provides guidance and stays on top of things until the format becomes self-sustaining. A two-week cycle has proven effective: enough time for preparation, research, or comparisons, while still keeping things moving. Sometimes approval from supervisors is needed so that participants can invest that three-quarter-hour. If interests diverge, the community may split.
Why is end-to-end testing so difficult in practice?
Because there are numerous tools, but no established methodology or best practices to build upon. Within their own applications and services, teams have everything under control. When it comes to system integration, the wrangling over who organizes what begins. Handoffs at the interfaces work only so-so; a discovered problem can sometimes slow the team down for two days.
Is testing with AI the same as testing AI?
No, these are two different worlds, and both require their own methods. When testing AI, the quality criteria shift fundamentally: Previously, testing was deterministic and based on fixed criteria; now, that very point of reference is gone. Developing new approaches for this is one of the ongoing challenges in quality assurance.
