Leaky Scrum, Squishy Testing

Eine Ausfallart von agilen Entwicklungsprozessen, die ich leider regelmäßig vorfinde, beruht auf der unzureichenden Verlagerung von Testing in das agile Entwicklungsteam. Dem Team ist es so nicht ausreichend möglich, seine Verantwortung für Qualität wahrzunehmen. Bleibt diese Situation unerkannt, kann sie sich destabilisieren und im schlimmsten Fall den Erfolg der Entwicklung infrage stellen. Es steht also einiges auf dem Spiel.

Die Symptome von Leaky Scrum, Squishy Testing im Endzustand sind schnell zusammengefasst:

• wachsende Qualitätsprobleme beim ausgelieferten Produkt,
• inkonsistente Lieferfähigkeit des Teams macht Planung unmöglich,
• schlechte Stimmung, Burnout und erhöhte Fluktuation.

Zum Glück braucht es etwas Zeit, bis es so schlimm aussieht. Aber wie können wir die Situation rechtzeitig erkennen und dagegen angehen?

Qualität ist Verantwortung des Entwicklungsteams

Letzte Woche habe ich beschrieben, wie sich Qualitätsverantwortung im agilen Kontext in die Entwicklungsteams verlagert. Entscheidend ist, dass alle notwendigen Testaktivitäten innerhalb des Entwicklungssprints stattfinden, so dass das fertige Inkrement den Qualitätsansprüchen eines Releases entspricht. Programmierer und Tester arbeiten eng zusammen, so dass gleichzeitig mit der Implementierung einer User Story auch die Abdeckung durch automatisierte Unit- und Komponenten-Tests fertiggestellt ist.

Was aber, wenn sich das Team dieser Verantwortung nicht bewusst ist oder ihr nicht nachkommen kann? Dann kommt es schnell zu einer typischen Abwärtsspirale, in der Qualität dem Zeitdruck weicht. Die Wirkkette sieht im Detail so aus:

1. Qualitätsprobleme: Kritische Bugs werden von der nachgelagerten QA, aus der Produktion oder sogar vom Kunden gemeldet und müssen im aktuellen oder einem der darauffolgenden Sprints behoben werden.
2. Lieferdruck: Die unvorhergesehenen Aufwände erschweren die Release-Planung, es ist unklar, ob Lieferfristen eingehalten werden können. Product Owner oder das übergeordnete Projektmanagement üben Druck auf das Team aus.
3. Ausbleibender Gegendruck: Das Team kann sich nicht auf eine klar bei ihm verortete Verantwortung für Qualität berufen und hält dem Druck nicht stand. Es akzeptiert die zusätzlichen Aufwände.
4. Aufgabe von Verantwortung: Das Team reduziert Testaktivitäten und Arbeiten an der Testbarkeit, um mehr Zeit für Implementierung zu haben. Qualität wird aus dem Fokus gedrängt.
5. Positive Rückkopplung: Die Qualität verschlechtert sich und es treten mehr kritische Bugs auf.

Es entsteht ein Teufelskreis. Aufgrund der schlechter werdenden Qualität entwickeln alle zunehmend unter Druck. Es ist zu Beginn eines Sprints unklar, was man am Ende eigentlich liefern kann. Die Entwickler sind frustriert, weil sie keine Gelegenheit haben, die nötigen Verbesserungen durchzuführen. Sie beginnen am agilen Entwicklungsprozess selbst zu zweifeln.

Kompensationsformen

Projekte, in denen ich dieses Bild vorfinde, sind in der Regel nicht am abbrennen. Stattdessen haben die Beteiligten reagiert und eine stabile Kompensationsform gefunden, die die oben beschriebene Abwärtsspirale stoppen soll. Drei davon will ich kurz skizzieren. Vielleicht kommt euch etwas davon bekannt vor.

• Die häufigste Kompensationsform kann als unvollständige Adoption von Agile Testing verstanden werden. Qualitätsprobleme werden durch eine Rückkehr zu einem der Entwicklung nachgelagerten Testing kompensiert. Vielleicht wurden auch tatsächlich Testaktivitäten nie vollständig in das agile Team verlagert, etwa weil das nötige Know-how fehlte. Jetzt ermöglichen es die Testergebnisse des Entwicklungsteams und der nachgelagerten QA gemeinsam die Qualität stabil zu halten.
• Sogenannte Stabilisierungssprints sind eine andere gängige Kompensation. Das sind ganze Sprints, die zum Ziel haben, die Qualität vor einem Release-Termin noch schnell zu verbessern. Implizit ist damit klar, dass die anderen Sprints nicht unbedingt auslieferbare Inkremente liefern.
• Etwas seltener sehe ich Pseudo-Kanban. Der Entwicklungsprozess wird auf einem Kanban-Board in Implementierung und Testing aufgeteilt. Es existieren aber keine WIP-Limits und Stories werden vom PO akzeptiert und im Review gezeigt, auch wenn sie nicht getestet sind. In der Regel ist implizit klar, wer für welche Spalten zuständig ist, und die Arbeit der Tester im Team wird damit marginalisiert.

Das Problem bei solchen Kompensationsformen ist, dass die Effektivität des Entwicklungsteams eingeschränkt wird. Zum Beispiel wird im ersten Fall eine nachgelagerte QA natürlich Fehler finden. Die Planung muss Zeit für deren Behebung vorsehen, und das Entwicklungsteam den mit Kontextwechseln verbundenen Verlust von Fokus und den erhöhten Stress bewältigen. Das nervt und kostet Zeit. Zeit, die weder in die Entwicklung noch in die Verbesserung der Testbarkeit und damit die nachhaltige Reduktion der Testaufwände investiert werden kann.

Auch die weitere Entwicklung des Teams und der Organisation wird gehemmt. Könnt ihr euch vorstellen, als DevOps-Team zum Beispiel mit Stabilisierungssprints zu arbeiten?

Wie ist die Lage?

In so einer Situation besteht die Gefahr, dass der Zustand unter Lieferdruck dekompensiert. Dem Team gelingt es dann nicht, ausreichenden Gegendruck aufzubauen, die oben beschriebene Abwärtsspirale läuft wieder los und die Qualität verschlechtert sich. Nur ein Team, das sich auf den eigenen Entwicklungsprozess und vereinbarte Qualitätsstandards berufen kann, ist in der Lage, auch einmal „Nein“ zu sagen.

Woran lässt sich erkennen, dass ein Problem vorliegt? Wenn ich mir ein Entwicklungsprojekt anschaue, achte ich auf eine Handvoll Kriterien, die sich aus der oben beschriebenen Wirkkette ableiten.

1. Qualitätsprobleme: Sind mehr als die Hälfte der Items im Sprint Backlog Bugs? Investiert das Team mehr als etwa 10 bis 20 Prozent seiner Entwicklungszeit in die Behebung von Defekten?
2. Lieferdruck: Sind PO oder Projektmanagement nervös bezüglich Lieferfristen? Ist aus ihrer Sicht gefühlt keine Zeit da, um die Qualität zu verbessern?
3. Ausbleibender Gegendruck: Enthält das Sprint Backlog etwa das eineinhalb- bis dreifache an Arbeit als man aufgrund der vorangegangenen Sprints erwarten würde? Werden WIP-Limits ignoriert?
4. Aufgabe von Verantwortung: Gibt es eine nachgelagerte QA? Enthält die Definition of Done nicht alle notwendigen Testaktivitäten? Wird sie nicht befolgt?
5. Dekompensation: Kommt die nachgelagerte QA mit dem Testen nicht nach? Müssen Features in Stabilisierungssprints fertig entwickelt werden? Stauen sich Tickets in der Testing-Spalte des Kanban-Boards?

Sind alle fünf Kriterien erfüllt, gehe ich davon aus, dass sich die Qualität in einer Abwärtsspirale befindet. Hier hilft leider nur, den Druck über längere Zeit zu reduzieren. Das Team muss die Gelegenheit haben, zu einer stabilen Kompensationsform zurück zu finden. Besser noch ist es, das Team im gleichen Zug zu befähigen seine Qualitätsverantwortung in vollem Umfang wahrzunehmen.

Damit sind wir wieder bei Leaky Scrum, Squishy Testing. Ein Scrum ohne geklärte Qualitätsverantwortung ist undicht, also leaky: Das Team kann keinen ausreichenden Gegendruck aufbauen, um die Produktqualität zu verteidigen. Software dringt so unfertig und mit Defekten in eine nachgelagerte QA, die Produktionsumgebung oder zum Kunden durch und sorgt so für Zusatzaufwände und Ärger.

Testing ist naturgemäß squishy: Es ist risikobasiert und Risiken manifestieren sich nicht unmittelbar. Nur weil ich einen bestimmten Test nicht durchführe, heißt das nicht, dass sofort ein Defekt auftritt, den der Test aufgedeckt hätte. Nur das Risiko wächst. Deshalb können Aufwände allzu leicht „wegrationalisiert“ und die Qualität kaputt gespart werden. Wenn Defekte dann schließlich auftreten, ist es nicht einfach, das ursprüngliche Maß an Qualität wiederherzustellen.

Leaky Scrum, Squishy Testing ist ein Problem, weil das Entwicklungsteam Lieferdruck nicht standhalten kann und seine Effektivität eingeschränkt wird. Die Entwicklungsarbeit ist stressiger und weniger erfüllend für alle Beteiligten. Potential zur Steigerung der Qualität und einer nachhaltigen Erhöhung der Entwicklungsgeschwindigkeit bleibt ungenutzt. Auch eine Weiterentwicklung der Organisation in Richtung DevOps wird schwieriger. Was hilft ist, den Druck zu reduzieren und Teams bei der konsequenten Umsetzung von Agile Testing zu unterstützen.