Quality Coaching im SAFe-Umfeld bezeichnet die Koordination von Entwicklungs- und Testaktivitäten über die Grenzen einzelner Teams hinaus. SAFe (Scaled Agile Framework) verbindet mehrere Teams in einem Agile Release Train, lässt aber eine Rolle offen, die übergreifende Qualität steuert. Quality Coaching füllt diese Lücke durch Anforderungscoaching, Prozessworkshops und Fehlermanagement auf allen Ebenen.
Das Wichtigste in Kürze
- Wer aus dem Wasserfall direkt in SAFe wechselt, bringt Altlasten mit: fixe Zieltermine ohne klaren Scope, bei denen Funktionalität so lange reduziert wird, bis der Termin passt, was Qualität systematisch untergräbt.
- Entwicklungsteams, die nur ihre eigene Story kennen, können keine übergreifende Qualität sichern: Fehler entstehen, weil niemand weiß, wie seine Komponente in den Gesamtgeschäftsprozess eingebettet ist.
- Eine physische Prozesssimulation, bei der Tester aus verschiedenen Teams ihre Abhängigkeiten gemeinsam durchspielen, schafft schneller ein geteiltes Produktverständnis als jedes Dokument.
- Fehler auf übergreifender Ebene bleiben liegen, weil sich kein Team verantwortlich fühlt: Ein benannter Fehlerkoordinator pro Release Train ist die pragmatische Lösung, bis Teams diese Verantwortung selbst übernehmen.
- Negativtestfälle und Edge Cases setzen fachliches Wissen voraus, das in SAFe-Transformationen oft auf keiner Ebene vollständig vorhanden ist und kaum effizient vom Solution-Level in die Entwicklungsteams transportiert wird.
Was ist Quality Coaching in SAFe
Quality Coaching ist eine Rolle, die Qualitätsverantwortung über die Grenzen einzelner Entwicklungsteams hinweg koordiniert. Sie schließt eine Lücke, die entsteht, wenn agile Skalierungsframeworks wie SAFe mehrere Teams auf ein gemeinsames Release und ein gemeinsames System zusammenführen.
Im agilen Arbeiten gilt: Qualität ist Sache des Entwicklungsteams. Jeder im Team trägt sie mit. In einem einzelnen Scrum-Team funktioniert das gut, solange das Team in seiner eigenen Blase arbeitet.
SAFe setzt über das Entwicklungsteam eine weitere Ebene: den Agile Release Train. Er verbindet die Arbeit mehrerer Teams auf ein Release hin. Damit müssen die Entwicklungsergebnisse der einzelnen Teams zueinander passen, und genau dieses Zusammenpassen muss getestet werden. Für diese Koordination ist in der Standardaufstellung niemand zuständig.
Quality Coaching ist dabei nicht nur Test-Koordination. Es ist je nach Situation auch Kommunikationscoaching, Anforderungscoaching und Methodencoaching. Alle Aspekte, die in Summe dafür sorgen, dass am Ende eine brauchbare Qualität herauskommt.
Warum die Qualitätslücke nach einer Transformation entsteht
Die Lücke entsteht, weil Teams in der Transformation von Wasserfall auf Agilität ein Arbeitsverständnis mitbringen, das auf das eigene Stück begrenzt ist. Wer jahrelang im Wasserfall gearbeitet hat, ist es gewohnt, seine Testfälle abzuarbeiten und fertig zu sein, wenn das eigene Ergebnis stimmt.
Ein Tester versteht nach der Umstellung oft noch, dass er seine Story testet und im Review als fertig meldet. Was danach kommt, gerät aus dem Blick: das Feature, das gemeinsam mit den Stories anderer Teams auf das System ausgerollt werden muss.
Diese Absprache zwischen Teams auf dasselbe Feature war nicht etabliert. Es war nicht mehr bekannt, dass sie überhaupt getan werden musste. Die Folge: Auf Entwicklungsebene wurden Variablen unterschiedlich vergeben, in der Fachlichkeit funktionierten Validierungen unterschiedlich. Auf demselben System führte das zu Widersprüchen.
Viele Beteiligte sind in dieser Situation schlicht überfordert. Sie wissen nicht, was sie tun müssen, damit das übergreifende Ergebnis funktioniert. Schon eine einfache Frage bleibt offen: Wenn zehn Entwicklungsteams in einem Agile Release Train arbeiten, wer stellt die Testumgebung, auf der alle zehn Teams testen? Jedes Team sagt zunächst, es sei nur für die eigenen Tests verantwortlich.
Wie man die Qualitätslücke analysiert
Jede Intervention beginnt mit Analyse. Bevor du etwas änderst, musst du verstehen, wie die Teams arbeiten und warum auf Produktebene bestimmte Fehler entstehen.
Dabei hilft es, die Fehlerursachen zu sortieren. Liegen die Fehler am methodischen Vorgehen? An der Kommunikation, weil A nicht mit B spricht? Oder sind es architektonische Fehler, weil schon in der Planung etwas falsch lief, weil der ganze Umfang nicht bekannt war?
Ein strukturiertes Interview entlang eines Fragebogens macht das Bild belastbar. Geführt wird es quer über alle Rollen und Ebenen: Tester in den Entwicklungsteams, Scrum Master, Product Owner, Product Manager und Engineers auf den höheren Ebenen. Die Leitfrage lautet jeweils: Wie verstehst du deine Verantwortung und deinen Einfluss im Hinblick auf das Gesamtprodukt?
Das Ergebnis solcher Interviews ist oft ernüchternd. Auf Entwicklungsteam-Ebene ist das Produkt teilweise völlig unbekannt. Ein Team weiß, dass es eine Schnittstelle um ein Attribut anpassen soll, aber nicht, was über die Schnittstelle übertragen wird und wie das in den Geschäftsprozess eingebettet ist. Dieser Wissensmangel reicht in manchen Fällen bis auf die Ebene des Agile Release Train hinauf, was bedeutet, dass von dort auch keine bessere Vorgabe kommen kann.
Geschäftsprozesse simulieren statt erklären
Ein wirksames Format, um übergreifendes Verständnis zu schaffen, ist die physische Simulation der Geschäftsprozesse. Tester aus den beteiligten Entwicklungsteams durchlaufen die kompletten Prozesse in einem Raum, mit Papier an der Wand.
Jeder übernimmt eine Rolle im Prozess. Einer ist der ID-Generator und erstellt eine ID. Der Nächste sagt, er brauche eine ID, suche dazu Daten und gehe in seine Datenbank. Die Datenbank liefert die angefragten Daten zurück. So wird der gesamte Prozess Station für Station durchgespielt.
Diese Simulation wirkt, weil sie Fragen beantwortet, die im Arbeitsalltag offen bleiben: Mit wem arbeite ich zusammen? Was tut der vor mir, was der hinter mir? Was genau braucht er, damit er arbeiten kann? Und was ist der Mehrwert des Ganzen für das Unternehmen?
Das Ergebnis ist eine eigene Identität im Gesamtkonstrukt. Wer den Prozess einmal durchlaufen hat, schaut in Entwicklung und Test nach rechts und links. Aus diesem Verständnis entstehen gemeinsame Tests über mehrere Teams: Ein Tester sagt dann, er wolle prüfen, dass das mit der ID und den Daten funktioniert, dafür brauche er drei andere Teams, und vereinbart einen Termin.
Anforderungen müssen erklärbar sein, sonst gehen sie zurück
Eine Anforderung, die nicht in kurzer Zeit verständlich erklärt werden kann, ist noch nicht reif für die Umsetzung. Aus dieser einfachen Regel lässt sich ein Filter bauen.
Die Faustregel im Coaching: Wenn ein Epic, ein Feature oder eine Story nicht in zehn Minuten so erklärt werden kann, dass in den fünf Minuten danach alle kritischen Fragen geklärt sind, geht das Ganze zurück. Dann ist es schlicht noch nicht so weit, dass jemand sinnvoll damit arbeiten kann.
Definition of Done und Definition of Ready sind im agilen Arbeiten vorausgesetzt und steuern, welche Qualität herauskommt. In einem Unternehmen, das sich kurzfristig für SAFe entscheidet, ohne das sauber zu durchdenken, sind diese Artefakte nicht von selbst da. Sie müssen erst etabliert werden.
Ein Team, das nur bedingt weiß, wie SAFe funktioniert, kann man nicht ohne Anleitung an diese Aufgabe setzen. Sonst entstehen Arbeitsergebnisse um der Ergebnisse willen, nicht um der Qualität willen.
Wer ist für die gemeinsame Testumgebung verantwortlich
Die Verantwortung für die übergreifende Testumgebung gehört in der agilen Aufstellung zum Systemarchitekten. Der erste und wichtigste Schritt ist allerdings, überhaupt zu erkennen, dass diese Verantwortung bisher bei niemandem liegt.
Auf Team-Ebene lässt sich die Federführung pragmatisch verteilen. Sinnvoll ist das Team, das bereits die umfangreichste Testumgebung mit den meisten Anbindungen an andere Services und Teams betreibt. Es wird federführend, die anderen Teams liefern zu. Damit liegt die Verantwortung dort, wo sie im agilen Modell hingehört: beim Entwicklungsteam.
An den Grenzen der Zuständigkeit hakt es trotzdem. Solange nicht jede Zulieferung sauber definiert ist, passt nicht alles zusammen. Hier kommt der Systemarchitekt zurück ins Spiel, der sich mit allen Schnittstellenpartnern zusammensetzen muss, um die Teile aufeinander abzustimmen.
Erschwerend wirkt die Mischung der Systemlandschaft. Neue Microservices stehen neben Legacy-Monolithen mit ganz anderen Release-Zyklen. Eine Umgebung, auf der alle gemeinsam testen können, ist trotzdem ein großer Schritt im Vergleich zum Ausgangszustand, in dem es gar keine gab.
Das Zielbild geht weiter: Releast ein Service eine neue Version, soll diese automatisch auf die Umgebung gespielt werden, und der Service selbst meldet proaktiv, dass es etwas Neues gibt. Heute laufen stattdessen oft Release Notes durch, aus denen erst herausgelesen werden muss, was auf die Testumgebung gehört. Aufwendig, aber funktional.
Fehlermanagement braucht einen klaren Koordinator
Fehler, die im übergreifenden Raum auftreten, brauchen einen benannten Koordinator, weil sich sonst niemand zuständig fühlt. In einem übergreifenden Raum war es keiner gewesen, und keiner möchte es gewesen sein.
Der Fehlerkoordinator nimmt für einen Agile Release Train oder eine Solution zunächst alle Fehler an. Er prüft, in welchen Bereich ein Fehler fällt, spricht mit dem Verantwortlichen dieses Bereichs, und der Verantwortliche zieht das passende Entwicklungsteam hinzu. Fehler werden also zentral gesammelt und koordiniert auf Arbeitsebene verteilt.
Bei der Verteilung auf mehrere Teams existieren parallel mehrere Wege. Ein Defekt wird nacheinander weiter assigned, oder er bekommt Tasks, an denen jedes Team einzeln arbeitet, oder er wird je Team geklont. Hier endet bewusst die Verantwortung des Quality Coaches, denn ein Eingriff in die agile Arbeitsweise schadet der Selbstorganisation der Teams.
Empfohlen wird ein einheitlicher Prozess, damit nichts durchrutscht. Diese Empfehlung wird in Retrospektiven mitgenommen, aber von den Teams oft mit dem Hinweis quittiert, ihnen rutsche nichts durch. Eine Haltung nah an der des Entwicklers, der sagt, er mache keine Fehler.
Fachlichkeit ist die größere Lücke als die Technik
Die größte offene Schwäche liegt nicht im technischen Testen, sondern im fachlichen Verständnis über die Teamgrenzen hinweg. Auf Team-Ebene funktionieren Komponententest und Integrationstest gut. Probleme treten auf der übergreifenden Ebene auf.
In der Ende-zu-Ende-Testkette ist das technische Verständnis der Anwendung oft noch da, das fachliche nicht mehr. Ein Tester ist dann technisch in der Lage, alle Kombinationen einer Schnittstelle durchzuprobieren, weiß aber für die Validierung nicht, ob ein bestimmter Fall überhaupt durchgehen darf.
Die Leute sehen nur, was in der Story steht. Wenn da nicht vom Gesamtgeschäftsprozess drinsteht, dass bestimmte Dinge nicht funktionieren dürfen, dann wissen die das nicht, dann testen sie das und dann ist das okay.
Andreas Neumeister
Solange die Fachlichkeit nur bedingt bekannt ist, bleiben Negativtestfälle und Edge Cases außen vor. Wer nicht weiß, was fachlich nicht passieren darf, kann es auch nicht prüfen. Der Happy Path wird getestet, der Rest fällt durch.
Es fehlt zudem ein effizienter Kanal, um fachliches Wissen von der Solution-Ebene über den Agile Release Train in die einzelnen Entwicklungsteams zu bringen. Spricht ein Solution Manager zu 20 oder 25 Teams, ist jeder Inhalt nur für eine Teilmenge relevant. Die nicht betroffenen Teams schalten ab, und 25 Mal dasselbe gezielt einzeln zu erzählen, hat niemand Zeit.
Zieltermine aus dem Wasserfall vergiften die Qualität
Wasserfall-Zieltermine, die unverändert in die agile Arbeitsweise übernommen werden, gehören zu den schädlichsten Altlasten einer Transformation. Im Wasserfall ließ sich auf feste Termine besser planen. Diese Termine wurden ins Agile mitgenommen, nun aber mit unklarem Scope, weil agil gearbeitet wird.
Das Ergebnis ist eine widersprüchliche Vorgabe: fester Termin, offener Umfang. Um den Termin zu halten, wird so lange an der Funktionalität geschraubt, bis es passt. Man erreicht den Zieltermin, hat aber nicht mehr die Anwendung, die man wollte.
Für die Qualitätssicherung ist dieses Vorgehen Gift. Funktionalität wird permanent herausgenommen, wieder hineingenommen, neu priorisiert, und an einer Stelle heißt es dann, mehr Funktionalität und weniger Tests. Solche Altlasten machen das Arbeiten in der Qualitätssicherung unnötig schwer.
Das eigentliche Ziel des Quality Coachings ist, sich selbst überflüssig zu machen. Der agile Grundgedanke, dass die Qualitätsverantwortung beim Entwicklungsteam liegt, ist erst dann erfüllt, wenn jeder diese Verantwortung annimmt, umsetzt und weiß, wie das geht. Und zwar nicht nur der Tester, sondern auch der Requirements Engineer und der Entwickler, getragen von einem gemeinsamen Qualitätsverständnis und gemeinsamen Qualitätszielen.
Häufig gestellte Fragen
Reicht es in SAFe, wenn jedes Entwicklungsteam für seine eigene Qualität sorgt?
Nein. In einem Agile Release Train führen mehrere Teams ihre Ergebnisse auf ein Release und ein gemeinsames System zusammen, und genau dieses Zusammenpassen muss getestet werden. In der Standardaufstellung ist dafür niemand zuständig. Quality Coaching übernimmt diese Koordination und verbindet sie je nach Situation mit Anforderungs-, Methoden- und Kommunikationscoaching.
Welche Ursachen haben Fehler, die erst im Zusammenspiel mehrerer Teams sichtbar werden?
Sie lassen sich drei Gruppen zuordnen: dem methodischen Vorgehen, der Kommunikation, wenn A nicht mit B spricht, und der Architektur, wenn schon in der Planung der volle Umfang unbekannt war. Typische Symptome sind unterschiedlich vergebene Variablen auf Entwicklungsebene und Validierungen, die fachlich verschieden arbeiten. Auf demselben System entstehen daraus Widersprüche.
Wie entsteht in einem Release Train ein gemeinsames Verständnis vom Gesamtprozess?
Schneller als über Dokumente entsteht es in einer physischen Simulation. Tester der beteiligten Teams durchlaufen die kompletten Geschäftsprozesse in einem Raum, mit Papier an der Wand, und jeder übernimmt eine Rolle: einer erzeugt die ID, der Nächste sucht dazu Daten, die Datenbank liefert zurück. Danach verabreden Tester von sich aus teamübergreifende Tests.
Woran erkennt man, dass eine Anforderung noch nicht umsetzungsreif ist?
An ihrer Erklärbarkeit. Als Faustregel gilt: Lässt sich ein Epic, ein Feature oder eine Story nicht in zehn Minuten erklären und sind nicht in den fünf Minuten danach alle kritischen Fragen geklärt, geht die Anforderung zurück. Definition of Done und Definition of Ready sind dabei kein Selbstläufer, sie müssen bei einer kurzfristigen SAFe-Einführung erst etabliert werden.
Wie lässt sich eine Testumgebung organisieren, auf der mehrere Teams gemeinsam testen?
In der agilen Aufstellung gehört diese Verantwortung zum Systemarchitekten. Pragmatisch übernimmt die Federführung das Team, das bereits die umfangreichste Testumgebung mit den meisten Anbindungen an andere Services betreibt, die übrigen Teams liefern zu. An den Zuständigkeitsgrenzen hakt es, solange Zulieferungen nicht sauber definiert sind. Dort stimmt der Systemarchitekt die Schnittstellenpartner ab.
Warum bleiben Fehler auf teamübergreifender Ebene häufig liegen?
Weil sich im übergreifenden Raum niemand als Verursacher sieht und keiner es gewesen sein möchte. Die pragmatische Lösung ist ein benannter Fehlerkoordinator pro Agile Release Train oder Solution. Er nimmt zunächst alle Fehler an, ordnet sie einem Bereich zu und spricht mit dessen Verantwortlichem, der das passende Entwicklungsteam hinzuzieht.
Warum werden Negativtestfälle und Edge Cases in skalierten Umgebungen oft nicht getestet?
Weil das fachliche Wissen fehlt, nicht das technische. Ein Tester kann alle Kombinationen einer Schnittstelle durchprobieren, weiß bei der Validierung aber nicht, ob ein bestimmter Fall überhaupt durchgehen darf. Steht in der Story nichts über den Gesamtgeschäftsprozess, wird der Happy Path geprüft und der Rest fällt durch.
Was passiert, wenn feste Zieltermine aus dem Wasserfall in die agile Arbeit übernommen werden?
Es entsteht die widersprüchliche Vorgabe fester Termin bei offenem Umfang. Um den Termin zu halten, wird so lange an der Funktionalität geschraubt, bis es passt: herausnehmen, wieder hineinnehmen, neu priorisieren, und an einer Stelle heißt es dann mehr Funktionalität und weniger Tests. Der Termin steht am Ende, die gewünschte Anwendung nicht.
