Qualität war der Punkt beim Agile Coaching

7 Min. Lesezeit

Bevor daraus Zeremonienverwaltung wurde

Was Qualität tatsächlich ist

Eine hübsche Oberfläche ist keine Qualität. Eine erfolgreiche Demo ist keine Qualität. Am Donnerstag durch die QA zu kommen und am Montag in Produktion zu kollabieren, ist keine Qualität.

Qualität in Software bedeutet, dass ein System tut, was es tun soll, dass es das auch dann noch tut, wenn die Realität hässlich wird, und dass es trotzdem veränderbar bleibt, ohne dass jede Verbesserung zur Operation am offenen Herzen wird.

Dazu gehören mindestens fünf Dinge:

• Die Software verhält sich für Nutzer und fürs Geschäft korrekt.
• Sie scheitert auf nachvollziehbare Weise, statt Daten still zu beschädigen.
• Sie lässt sich ändern, ohne drei andere Baustellen gleich mit zu sprengen.
• Teams können erkennen, ob sie gesund ist, weil Feedback schnell und echt kommt.
• Die Menschen, die sie bauen, können die Arbeit dauerhaft leisten, ohne in Angst und Nacharbeit zu ertrinken.

Dieser letzte Punkt wird gern ignoriert, weil er weich klingt. Ist er nicht. Ein Team, das in ständiger Angst lebt, produziert keine Qualität. Es produziert Tarnung. Menschen verstecken Unsicherheit, bündeln riskante Arbeit, meiden fragile Bereiche und definieren “fertig” so lange neu, bis Führung ruhig schlafen kann.

Qualität ist nicht nur eine Eigenschaft des Produkts. Sie ist auch eine Eigenschaft der Art, wie das Produkt gebaut wird.

Was Agile Coaching ursprünglich bedeutete

Als Agile Coaching noch einen Puls hatte, besonders in der frühen amerikanischen Szene rund um Extreme Programming, Scrum in seiner noch nicht komplett sterilisierten Form und die breitere Agile-Bewegung vor ihrer Industrialisierung, war die Arbeit sehr viel konkreter.

Ein Coach sollte Teams dabei helfen zu lernen, wie man Software in kleineren Schritten baut, mit schnellerem Feedback, besserer Zusammenarbeit und stärkerer technischer Disziplin. Das hieß Pairing. Test-first-Denken. Continuous Integration. Refactoring. Echtes Kundenfeedback. Arbeit so klein geschnitten, dass sie fertig werden konnte. Gespräche nah genug am Code, damit Missverständnisse nicht erst in Produktion landen.

Im Zentrum dieser Arbeit stand Qualität.

Nicht Qualität als Tor am Ende. Qualität als etwas, das von Anfang an durch Feedback, Entwurf und technische Praxis eingebaut wird.

Darum kam technische Exzellenz in der alten Agile-Sprache überhaupt vor. Nicht als dekorative Philosophie. Sondern als mechanische Grundlage für Anpassungsfähigkeit. Wenn der Code spröde ist, Tests fehlen, Integration Angst macht und Deployment ritualisiert ist, dann sind Sie nicht agil. Dann verschieben Sie nur Panik im Kalender.

Ein nützlicher Coach in diesem älteren Sinn hat nicht bloß Workshops moderiert. Er hat verändert, wie Arbeit stattfindet. Er hat Teams geholfen, Defekte früher zu sehen, Batchgrößen zu reduzieren, Risiken sichtbar zu machen und Vertrauen durch ausführbare Evidenz aufzubauen.

Wie es entgleist ist

Die ernsthafte technische Variante war schwerer zu verkaufen.

Sie verlangte nach erfahrenen Praktikern. Sie verlangte Glaubwürdigkeit bei Entwicklern. Sie verlangte, sich hässlichem Code, kaputten Pipelines, schwacher Teststrategie und Managementgewohnheiten zu nähern, die die falschen Dinge belohnten. Sie verlangte Konflikt.

Also tat der Markt, was Märkte eben tun. Er fand die billigere Variante.

Plötzlich ließ sich Agile Coaching auch ohne starke technische Grundlage verkaufen. Man musste nicht mehr wissen, wie man einem Team hilft, Qualität in den Code einzubauen. Es reichte, zu moderieren, umzudeuten, Empathie zu zeigen, Haftnotizen zu sortieren und sichere Worte für organisatorisches Unbehagen einzuführen.

In den Vereinigten Staaten wurde daraus oft Methodenberatung im Gewand von Transformation. In Europa bekam es oft eine noch seltsamere soziale Rolle: eine Art Straßenarbeit für Softwareteams. Jemand, der Menschen beruhigt, Frust aufnimmt, Kommunikation am Laufen hält, Schmerz in harmlose Sprache übersetzt und dem System das Gefühl gibt, versorgt zu sein, ohne es zu zwingen, sich zu ändern.

Diese Arbeit ist nicht immer nutzlos. Menschlicher Konflikt ist real. Teamstress ist real. Aber sie ist kein Ersatz dafür, Softwarelieferung zu verbessern. Oft wird sie zu einer Methode, Menschen beim Überleben in einem schlechten System zu helfen, statt zu konfrontieren, warum dieses System überhaupt ständig minderwertige Software hervorbringt.

Warum der Markt die schlechtere Version bevorzugte

Diese Verschiebung war nicht nur berufliche Korruption. Sie war auch Psychologie.

Echte Qualitätsarbeit bedroht Menschen.

Sie bedroht Führungskräfte, weil sie sichtbar macht, dass Termine, Finanzierungsentscheidungen und Berichtslinien das Produkt beschädigen könnten. Sie bedroht Manager, weil sie offenlegt, wie wenig sich an Lieferung mit Planungstheater reparieren lässt. Sie bedroht Entwickler, weil echte technische Disziplin die Romantik heldenhafter Improvisation zerstört. Sie bedroht Berater, weil messbare Verbesserung schwerer zu fälschen ist als Moderationsenergie.

Prozesstheater dagegen ist emotional bequem.

Es gibt Führung eine sichtbare Intervention. Es gibt Managern ein Vokabular. Es gibt Teams ein Ritual. Es gibt Beratern ein produktisiertes Angebot. Es gibt allen eine Geschichte, in der sie sich sehr anstrengen.

Diese Geschichte hat enormen psychologischen Wert. Sie senkt Angst, ohne dass man den realen Ursachen schlechter Qualität direkt ins Gesicht sehen muss.

Bedürfnisse, Status und die seltsame Ökonomie von Qualität

Hier kommt der hässliche Teil.

Viele Käufer wollen die Disziplin, die für Qualität nötig ist, gar nicht wirklich. Sie wollen das Gefühl, verantwortlich gehandelt zu haben.

Das ist ein anderes Bedürfnis.

Manche wollen Status: “Wir haben Agile Coaches geholt. Jetzt sind wir modern.” Manche wollen Absolution: “Wenn Lieferung trotzdem scheitert, haben wir wenigstens Best Practice befolgt.” Manche wollen sozialen Frieden: “Bitte reduziert Konflikte, ohne Anreize zu verändern.” Manche wollen billige Hoffnung: “Können wir die Vorteile technischer Exzellenz bekommen, ohne Kosten, Zeit oder Unbehagen?”

Und der Markt reagiert wunderschön auf diese Bedürfnisse.

Er liefert Verbesserungstheater zu einem Preis und in einem Ton, den der Käufer aushält. Nicht zu konfrontativ. Nicht zu technisch. Nicht zu fordernd. Gerade genug Sprache über Haltung, Zusammenarbeit und Reifegrad, damit es ernst klingt.

Es wird immer jemanden geben, der billige Versprechen von bester Qualität kauft, solange die Geschichte tröstlich genug ist. Und es wird immer jemanden geben, der sie verkauft.

Das ist kein Agile-Sonderfall. So verhalten sich die meisten Märkte mit wenig Rechenschaft. Wenn der Käufer die zugrunde liegende Qualität nicht leicht prüfen kann, gewinnt Verpackung lange Zeit.

Software ist besonders anfällig, weil Qualität meist unsichtbar bleibt, bis sie in der Öffentlichkeit zerbricht.

Die psychologische Spaltung in Teams

Hier wird der menschliche Preis sichtbar.

Entwickler, denen Qualität wichtig ist, erleben das System meist als Strom vermeidbarer Kompromisse. Sie sehen die fehlenden Tests, die gefährliche Kopplung, die Batchgrößen, die stillen Risiken, die falschen Schätzungen, die Angst vor Deployment. Für sie ist Qualität konkret.

Führung erlebt dieselbe Lage oft anders. Sie sieht Termine, Budgets, Druck aus dem Aufsichtsrat, Personalengpässe und den ständigen Zwang, die Organisation zusammenzuhalten. Für sie wird Qualität schnell zu einer abstrakten Sehnsucht, die mit allem anderen konkurrieren muss.

Der Coach sollte ursprünglich helfen, diese Lücke durch Evidenz, Praxis und gemeinsame Feedbackschleifen zu überbrücken. In der entwerteten Version wird der Coach oft zum Puffer, der beiden Seiten hilft, die Lücke auszuhalten, ohne sie wirklich zu schließen.

Das ist ein massiver Abstieg.

Er verwandelt Coaching von Fähigkeitsaufbau in emotionale Stoßdämpfung.

Was ein qualitätsorientierter Coach heute noch tun würde

Wenn die Rolle überhaupt etwas wert sein soll, muss sie zumindest diese Dinge tun:

• Teams helfen, Arbeit kleiner zu schneiden, damit Feedback eintrifft, bevor sich Schaden aufschichtet.
• Die technischen Praktiken stärken, die Veränderung sicher machen.
• Qualität durch Tests, Liefersignale, Defekte und Produktionsverhalten sichtbar machen.
• Führung dabei coachen, Evidenz statt Rituale zu lesen.
• Die Abhängigkeit vom Coach mit der Zeit verringern, statt eine dauerhafte Übersetzerkaste zu schaffen.

Darum muss Führung den Weg selbst verantworten, und darum wird Methodik gefährlich, wenn sie Realität durch Loyalität ersetzt. Der Job war nie, mehr Prozess zu installieren. Der Job war, die Fähigkeit des Systems zu verbessern, hochwertige Software hervorzubringen.

Der Markt wird weiter Theater kaufen

Dieser Teil verschwindet nicht.

Es wird immer Käufer geben, die eine saubere Methode lieber haben als eine unbequeme Diagnose. Es wird immer Berater geben, die minderwertige Systeme vorübergehend raffiniert klingen lassen. Es wird immer Organisationen geben, die etwas Qualität nennen, weil es freigegeben, dokumentiert oder mit einer Zeremonie umrahmt wurde.

Gut. Sollen sie.

Für die, die tatsächlich Qualität wollen, muss die Definition scharf bleiben.

Qualität ist Software, die unter realen Bedingungen funktioniert, veränderbar bleibt und durch diszipliniertes Feedback gebaut wird statt durch zeremonielle Beruhigung.

Das war der ernsthafte Kern des Agile Coachings, bevor der Markt ihn verdünnt hat.

Er ist noch immer der einzige Teil, den man behalten sollte.