Quality Coaching

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