Quality Coaching bezeichnet einen Bottom-up-Ansatz zur Qualitätsverbesserung in Softwareteams, bei dem Methodiken wie Drei-Amigos-Sessions, Risk Storming oder Communities of Practice gezielt eingesetzt werden, um Teams zur Selbsthilfe zu befähigen. Das Ziel ist nicht, Lösungen von außen vorzugeben, sondern Wissen in die Mannschaft zu tragen, bis externe Unterstützung nicht mehr gebraucht wird.
Das Wichtigste in Kürze
- Quality Coaching unterscheidet sich von klassischer Beratung durch einen Bottom-Up-Ansatz: Interviews mit dem Team legen die eigentliche Problemursache frei, nicht nur das Symptom, das das Management benennt.
- Die Drei-Amigos-Methode, bei der Anforderung, Entwicklung und Test eine User-Story gemeinsam durchdenken, reduziert Diskussionspunkte im Refinement deutlich, weil alle vorab verstehen, was die Akzeptanzkriterien sind.
- Der größte Coaching-Erfolg ist erreicht, wenn der Kunde die erlernten Methoden selbstständig anwendet und den Coach nicht mehr braucht.
- Communities of Practice brauchen am Anfang einen dedizierten Moderator, der sie ins Laufen bringt; das Zwei-Wochen-Intervall gibt den Teilnehmern genug Zeit zur Vorbereitung und sorgt für einen stabilen Rhythmus.
- Testumgebungen sind unabhängig vom Prozessmodell, ob CI/CD, Wasserfall oder agil, ein dauerhaftes Problemfeld, in dem unverhältnismäßig viel Zeit und Geld verloren geht.
Was Quality Coaching von klassischer Beratung unterscheidet
Quality Coaching setzt unten an, nicht oben. Statt eine fertige Lösung ins Projekt zu tragen, arbeitet ein Quality Coach mit dem Team an der Ursache des Problems und befähigt die Leute, Methoden selbst anzuwenden.
Der Unterschied zeigt sich in der Herangehensweise. Viele Consultants bringen einen festen Ansatz mit, den sie an einer bestimmten Stelle ausrollen. Coaching geht den umgekehrten Weg über Interviews und direkten Kontakt zur Mannschaft, die täglich im Projekt arbeitet.
Diese Nähe bringt Informationen ans Licht, die im Management-Bild fehlen. Bastian Baumgartner beschreibt einen Fall, in dem ein Kunde alle Testmanager, Testautomatisierer und Tester unter einem Titel zusammenfasste. In den Gesprächen kamen echte Jobängste hoch, weil die Leute nicht wussten, ob ihre Skills zur neuen Rolle passten.
Der Maßstab für gute Beratung ist dabei klar.
Der größte Erfolg von Beratern ist, wenn die Kunden uns nicht mehr brauchen. Wenn wir es geschafft haben, sie zu befähigen, die Methoden selbst umzusetzen.
Bastian Baumgartner
Warum Wissen oft nicht in der Mannschaft ankommt
Ein verbreitetes Muster bei agilen Transformationen: Das Management bekommt einen Quality Coach, aber das Wissen wird nicht weitergetragen. Probleme entstehen erst im Test, und dann werden Berater geholt.
Genau hier rutscht man schnell in die Coaching-Rolle. Man zeigt Methoden, die das Management vielleicht längst kannte, die aber in der Mannschaft nie angekommen sind. Mit kleinen Methoden lässt sich an dieser Stelle eine große Wirkung erzielen.
Drei Amigos: Klarheit vor dem Refinement
Drei Amigos ist eine Methode, bei der drei Disziplinen eine User Story besprechen, bevor das Team ins Refinement geht. Der Name meint die Disziplinen, nicht die Personenzahl am Tisch.
Beteiligt sind die Anforderungsseite, oft ein Product Owner oder ein technischer PO, die Entwicklung und der Test. Gemeinsam klären sie, wie die Story umgesetzt und wie sie getestet werden kann. Eine Trennung in technische und fachliche Tests ist dabei üblich.
Der Effekt zeigt sich später. Wenn allen klar ist, was mit der Story passieren soll und wodurch die Akzeptanzkriterien erreicht werden, fallen die langen Diskussionen im Refinement weg. Ein Kunde zweifelte zunächst an der zusätzlichen Dreiviertelstunde, sah dann aber, wie viel schneller das Team alle Storys geschätzt bekam und fertig wurde.
Der Methodenkoffer für den Einstieg ins Team
Quality Coaches arbeiten mit einem Methodenkoffer, aus dem sie passend zum Kunden auswählen. Der Einstieg läuft meist über Interviews, weil sie den besten Überblick geben, wo der Schuh wirklich drückt.
Die Ergebnisse der Interviews werden anonymisiert und zu Clustern gebündelt. Aus den Top 3 oder Top 5 Themen leitet sich die weitere Arbeit ab. Häufig folgt ein Discovery Workshop, dessen Form sich nach der Organisationsstruktur des Kunden richtet.
Einige bewährte Formate aus der Praxis:
- Pains und Gains: Die Teilnehmer schreiben die drei größten Schmerzpunkte im Testprozess und die drei wirksamsten Handlungsfelder auf Post-its, die an die Wand kommen und zu Clustern werden.
- Risk Storming: Liefert eine gute Grundlage, etwa um eine Teststrategie zu entwickeln.
- Find-the-Bug-Sessions: Ein gemeinsamer explorativer Test, damit die Leute sehen, wie das funktionieren kann.
- Testing-Touren: Strukturierte explorative Ansätze für den praktischen Einsatz.
- Testing for Non-Testers: Grundlagen für Rollen außerhalb des Tests, etwa für einen Scrum Master, der mehr in Richtung Test-Impediments geschult werden soll.
Die wiederkehrenden Pains: Testumgebungen und Skill-Up
Manche Probleme tauchen unabhängig vom Vorgehensmodell auf. Ob CI/CD, Water Scrum oder anderes: Testumgebungen kosten überall viel Zeit und Geld.
Gutes Management von Testumgebungen ist deshalb ein eigenes Kapitel in der Ausbildung zum Testmaster bei Quality Minds. Aus der Arbeit mit Kunden sind dazu Best Practices entstanden, die auch ins Release Management einzahlen.
Der zweite Dauerbrenner ist der Skill-Up der Tester. In agilen Teams wird erwartet, dass ein Tester Automatisierungs-Skills mitbringt. Das heißt nicht, dass jeder Java programmieren muss. Vieles lässt sich über das passende Toolset steuern.
Best Practices anderer sind Best Practices anderer
Agile Frameworks werden in der Praxis nie eins zu eins nach Lehrbuch umgesetzt. Niemand fährt Scrum, Scrum of Scrums, LeSS oder SAFe zu 100 Prozent nach Vorlage. Es wird immer adaptiert.
Selbst das Spotify-Modell funktionierte nur bis zu einem bestimmten Punkt. Als das Unternehmen zu groß wurde, lief es nicht mehr rund, obwohl der Name darauf steht.
Daraus folgt ein praktischer Rat für Teams: Du darfst dir die guten Teile herauspicken und nutzen. Du musst kein Framework vollständig übernehmen. Das Framework dahinter spielt im ersten Moment keine Rolle, es geht darum, den Leuten beim Lösen ihrer Probleme zu helfen.
Ein Kritikpunkt bleibt bei den Skalierungs-Frameworks: Der Test ist dort oft komplett außen vor.
Warum der Mindset-Change die größte Herausforderung ist
Die größte Hürde im Coaching ist nicht die Methode, sondern der Mindset-Change. Besonders schwer wird es in Unternehmen mit klaren Hierarchien und festen Strukturen.
Die Erwartung lautet oft, dass man von einem Geschäftsjahr aufs nächste in die agile Softwareentwicklung umschwenkt und alle Mitarbeiter mitziehen. Das funktioniert nicht ohne Unterstützung. Viele Leute haben 15 oder 20 Jahre in einer Organisation gearbeitet.
Tester tun sich besonders mit der Selbstorganisation schwer. Jahrelang haben Testmanager ihnen die Tickets vor dem Sprint zugeschoben. Jetzt sollen sie sich Aufgaben selbst holen und Eigenverantwortung übernehmen. Dieser Wechsel braucht Zeit.
Community of Practice: wie sich das Mindset wirklich ändert
Eine Community of Practice ist ein organisierter Zusammenschluss zu einem Themengebiet, der sich im Idealfall selbst leitet und organisiert. Genau hier lässt sich beobachten, wie sich das Mindset über die Zeit verändert.
Bei Kunden wurde etwa eine Community of Practice für Tester ins Leben gerufen, mit vorab abgestimmten Themen. Im Mittelpunkt steht der Erfahrungsaustausch: Wer ein neues Tool oder eine Methode erfolgreich eingesetzt hat, stellt sie vor. So wird das Voneinander-Lernen gefördert. Intern läuft das bei Quality Minds als Format namens “Let’s Test” alle zwei Wochen.
Ein Zwei-Wochen-Turnus hat sich bewährt. Er lässt genug Zeit zur Vorbereitung, für Recherche oder Vergleiche, und hält die Community trotzdem in Bewegung. Wenn die Interessen zu weit auseinanderlaufen, kann eine Community sich aufspalten, etwa in einen eigenen Strang für Testautomatisierung.
Ein neu etabliertes Format läuft nicht von allein. Es braucht anfangs einen Moderator oder Community Manager, der anleitet und dranbleibt, bis das Ganze selbst trägt. Manchmal braucht es sogar die Freigabe von Vorgesetzten, damit die Teilnehmer die Dreiviertelstunde alle zwei Wochen investieren dürfen.
Qualität entsteht im Team, nicht im Test
Qualität ist das Ergebnis des Gesamtprozesses. Man kann Qualität nicht am Ende in ein Produkt hineintesten, deshalb muss das ganze Team eingebunden sein, nicht nur die Tester.
Der Test sitzt traditionell am Ende der Nahrungskette. Mob-Testing-Sessions holen alle früher an einen Tisch. In einem Driver-Navigator-Ansatz sitzt eine Person vorn und testet, während die anderen reihum jeweils zwei Minuten lang vorgeben, wie getestet werden soll.
Der Lerneffekt entsteht aus den unterschiedlichen Perspektiven. Das Team sieht, wie ein Entwickler an die Sache herangeht und wie ein Softwarearchitekt. Dieser Wissensaustausch ist der Whole-Team-Approach in der Praxis.
Ressentiments gegen den Testkram begegnen einem heute seltener. Durch die Agilität sind Entwickler und Tester näher zusammengerückt, der frühere Graben ist deutlich kleiner geworden. Entwickler sehen den Mehrwert, wenn Tester sich technisch ein Skill-Up holen und beide bei der Automatisierung voneinander lernen.
Wo das größte Potenzial liegt: End-to-End und KI
Zwei Themen prägen die nächste Phase der Qualitätsarbeit: End-to-End-Testing und KI.
Beim End-to-End-Testing fehlt eine etablierte Methodik. Es gibt zahlreiche Tools, aber keine Best Practices, auf denen man aufsetzen kann. Solange Teams in ihrer eigenen Applikation und ihren eigenen Services bleiben, haben sie alles im Griff. Sobald es Richtung Systemintegration geht, entstehen Unklarheit und Gerangel darum, wer was organisiert.
Das Problem verschärft sich, wo viel Fachspezifik in den Testfällen steckt. Dann testen Leute aus der Fachabteilung UI-getrieben mit, was Ressourcen bindet und lange Testaktivitäten erzeugt. Staffelstabübergaben an den Schnittstellen funktionieren mittelprächtig, und ein entdecktes Problem kann das Team auch mal zwei Tage ausbremsen. Verschärfend kommt hinzu, dass immer mehr Unternehmen Software bauen, um ein anderes Produkt herzustellen, etwa ein Auto, und entsprechend hemdsärmelig unterwegs sind.
Bei KI scheiden sich die Geister an einer Unterscheidung: Teste ich mit KI oder teste ich KI? Das sind zwei verschiedene Welten, und für beide braucht es eigene Methoden. Der Zugang ändert sich grundlegend, denn die Qualitätskriterien werden andere. Früher prüfte man deterministisch gegen feste Kriterien. Genau dieser Punkt verschiebt sich, und Quality Coaches sind gefragt, dafür neue Ansätze zu entwickeln.
