Transparenz und Qualitätskontrolle in agilen Projekten

Agile Selbstheilungsmechanismen

Jörn Koch und Sebastian Middeke

Agile Methoden sind das aktuelle Heilsversprechen der Softwaretechnik. Agiles Vorgehen ist heutzutage nicht mehr revolutionär, sondern in weiten Kreisen etabliert und anerkannt. Und das zu Recht, denn agile Techniken besitzen viele Vorteile. Und doch zeigt die Erfahrung, dass agile Techniken allein keinen agilen Prozess garantieren. Trotz User-Stories, Timeboxing und Daily Scrums feiern altbekannte Probleme, die doch mit dem agilen Ansatz gebannt sein sollten, fröhliche Wiederkehr: Budgets und Deadlines werden überzogen, die Qualität stimmt nicht, der Kunde bleibt auf nicht umgesetzten Kernanforderungen sitzen usw. Wir werfen in unserem Artikel einen kritischen Blick auf den Qualitätsaspekt und zeigen Techniken auf, um durch hohe Qualität Planungssicherheit und eine hohe Teamgeschwindigkeit zu erreichen.

Agile Projekte sind selbstorganisierend. Allerdings sehen wir auch, dass diese Selbstorganisation nur innerhalb der Grenzen des jeweiligen Projekts greift. Wir erleben oft, dass Innensicht des agilen Projekts und Außensicht des Unternehmens auf das agile Projekt kollidieren. Gerade im Konfliktfall zeigt sich, dass das Projektgeschehen sehr intransparent ist und eine gemeinsame Sicht fehlt.

Transparenz lässt sich über die üblichen agilen Kennzahlen nicht immer ausreichend herstellen. Das ist überraschend, da Feedback doch der zentrale Mechanismus agilen Vorgehens ist! Das agile Feedback trägt offenbar nicht weit genug nach außen. Aber auch die Innensicht ist nicht vor Fehleinschätzungen des Projektzustands geschützt: Besonders oft beobachten wir, dass ein voll ausgelastetes Team der Meinung ist, dass alles „perfekt rundläuft“ und doch weniger produktiv ist, als es die Zahl der bearbeiteten Stories und Bugs vermuten lässt.

Mit den im Folgenden beschriebenen Mitteln können Sie für agile Projekte Problemsituationen sicherer erkennen, einschätzen und deutlich kommunizieren. So können Sie im Bedarfsfall leichter Korrekturmaßnahmen einfordern, die außerhalb der Entscheidungskompetenzen des Projekts liegen.

Qualität bedeutet Planungssicherheit

Um Innen- und Außensicht zusammenzubringen, braucht es Gemeinsamkeiten. Das gemeinsame Verständnis des Projektziels – also eine Software in der geforderten Qualität „on time, on budget“ zu produzieren – ist dafür ein sehr guter Ansatzpunkt: Diese gemeinsame Sicht entsteht, wenn aus Innen- und Außensicht gleichermaßen „transparent“ (erkennbar) ist, inwieweit das Projektziel voraussichtlich erreicht oder verfehlt wird.

Wie erfolgreich ein agiles Projekt durchgeführt wurde, erkennen wir anhand der klassischen vier XP-Variablen „Cost, Time, Quality and Scope“, die allesamt im geforderten Rahmen liegen müssen. Dabei spielt die Qualität allerdings eine Sonderrolle: Sie muss über die gesamte Projektlaufzeit stimmen, um relevantes Feedback erwarten zu können. Prototypisches, Halbfertiges und Fehlerhaftes lässt sich nicht testen und abnehmen. Die kontinuierliche Qualitätskontrolle (QK) nimmt somit eine zentrale Position im agilen Projekt ein und liefert neben dem Nachweis einer hohen Produktqualität auch wichtige Anhaltspunkte zur Beurteilung des Projektzustands.

Eine hohe Qualität ist aber auch für eine hohe Entwicklungsgeschwindigkeit notwendig. Das scheint auf dem ersten Blick paradox, denn es ist naheliegend, an der Qualität zu sparen, wenn z. B. die Zeit knapp wird (Stichwort „Quick & Dirty“). Diese Rechnung geht jedoch nur auf, wenn die „Mindestqualität“, die der Kunde erwartet, nicht unterschritten wird.

Wird sie beispielsweise durch Fehler oberhalb eines bestimmten Schweregrads unterschritten, sind Nacharbeiten wie Bugfixes und Nachtests nötig. Die dafür notwendigen Aufwände können sehr unterschiedlich ausfallen und lassen sich naturgemäß nicht einplanen, bevor die Fehler nicht gefunden und analysiert wurden.

Wir erleben oft, dass ein pauschaler „Bugfixing-Overhead“ vorgeschlagen wird, der jedoch zu einem unsauberen Entwicklungsstil einlädt und das grundsätzliche Problem nicht lösen kann. Nachbesserungsaufwände sind kein kontinuierlicher Overhead! Sie bedeuten einen Stillstand für eine gewisse Zeit: Das Team arbeitet daran, einen vermeintlich bereits vorhandenen Stand zu erreichen. Bugfixing ist somit – streng genommen – eine ungeplante, unproduktive Tätigkeit.

Interessanterweise erleben wir oft, dass Entwicklungsteams häufiges Bugfixing nicht als problematisch empfinden – im Gegenteil: Bugfixing erscheint höchst produktiv, da die Qualität des Produkts dadurch stark verbessert wird. Diese Wahrnehmung stimmt natürlich, allerdings nur, wenn man das fehlerhafte Produkt als Ausgangspunkt nimmt und nicht das eigentlich angenommene fehlerfreie Produkt.

Nacharbeiten aufgrund von Qualitätsmängeln sind in der Regel nicht planbar: Bugs werden entdeckt und müssen zeitnah behoben werden, wenn es der Schweregrad verlangt. Zudem ist es generell wichtig, Fehler zeitnah zu beseitigen, da sonst Fehlermaskierungen drohen (d. h., ein Fehler verhindert die Aufdeckung eines anderen). Es wird durch derartige unplanbare Nacharbeiten zu einem riskanten Unterfangen, „on time, on budget“ abzuliefern. Je später Stillstand im Projekt entsteht, desto unrealistischer ist es, ihn durch eine höhere Teamgeschwindigkeit zu kompensieren (Abb. 1), und umso höher ist die Gefahr, Deadline und Budget zu überziehen oder den vereinbarten Scope nicht abzuliefern.

Abb. 1: Später Stillstand im Projekt lässt sich nur durch unrealistische Teamgeschwindigkeit kompensieren

Die Teamgeschwindigkeit berechnen wir hierbei auf Basis der Aufwände eines product increment, soweit es von der QK zur Abnahme empfohlen wurde (unter der Voraussetzung, dass auch die Regressionstests erfolgreich verlaufen sind). Der Kern unserer definition of done lautet also: „QK erfolgreich!“. Die Teamgeschwindigkeit basiert daher auf dem durch die QK nachgewiesenen Projektfortschritt. (Anmerkung.: Wir setzen voraus, dass die Tests der QK in Umfang und Qualität geeignet sind, die Umsetzung der (Mindest-)Anforderungen nachzuweisen.)

Eine wichtige Konsequenz aus diesem Nachweis ist, dass die Arbeit an den umgesetzten Anforderungen tatsächlich als abgeschlossen angesehen werden darf: Ungeplante Nacharbeiten in diesen Bereichen sind nicht zu erwarten. Die planmäßig zur Verfügung stehenden Ressourcen werden voraussichtlich nicht für Nachbesserungsarbeiten abgezogen werden müssen. Der Nachweis des Projektfortschritts durch die QK ist eine wichtige Voraussetzung (neben Risikominimierung, personeller Kontinuität etc.), um im Projekt Planungssicherheit zu erreichen.

Umgekehrt betrachten wir product increments, die von der QK in Teilen abgelehnt wurden, als „offene Baustellen“: Zum einen stehen konkrete Nacharbeiten an, zum anderen können Nachtests aufgrund von Fehlermaskierungen weitere Nacharbeiten erfordern. Die Arbeit am product increment ist somit nicht abgeschlossen, sondern work in progress (WiP). Derartige aufgeschobene Nacharbeiten können sich anhäufen und zu einem unkalkulierbaren Risiko werden (Abb. 2).

Abb. 2: Risikofaktor „work in progress“ (WiP) – vereinfachte Darstellung

Aufwände zur Qualitätssicherung sind dagegen schätzbar und planbar. Selbst QK-Aufwände können geschätzt werden, sofern „die Qualität stimmt“, d. h. Nachtests einen vernachlässigbaren Anteil an den QK-Aufwänden haben.

The Good, the Bad, and the Ugly Iteration

Eine der höchsten Prioritäten sollte also sein, das geforderte Qualitätsniveau herzustellen und mit allen Kräften zu erhalten. Statt: „Wir haben keine Zeit für gute Qualität“, gilt eher: „Wir haben keine Zeit, uns mit den Folgen schlechter Qualität herumzuschlagen“.

Agile Projekte besitzen wirkungsvolle „Selbstheilungsmechanismen“, wie z. B. die Retrospektive, die geeignet sind, bis zu einem gewissen Maß Qualitätsmängel wieder auszugleichen. Woran erkennen wir jedoch, ob diese „Selbstheilungsmechanismen“ noch ausreichen oder ob tiefgreifende Maßnahmen erforderlich sind, die möglicherweise nur das Management beschließen kann?

Wir haben drei Typen von Iterationen identifiziert, „good“, „bad“ und „ugly“, die sich vor allem in zwei miteinander korrespondierenden Merkmalen unterscheiden:

  • Qualitätsniveau des product increment
  • Teamgeschwindigkeit

Iterationen, in denen Qualitätsniveau und Teamgeschwindigkeit hoch sind, nennen wir „good“. Iterationen, in denen das Qualitätsniveau so gering ist, dass die Teamgeschwindigkeit gegen null geht, nennen wir „bad“. Alle Zwischenstufen, in denen häufige Nacharbeiten aufgrund des niedrigen Qualitätsniveaus nur eine geringe Teamgeschwindigkeit zulassen, nennen wir „ugly“.

Die Zielsetzung, die diesen Iterationen zugrunde liegt, ist in allen drei Fällen gleich: Mit jeder Iteration soll ein potentially shippable product increment abgeliefert werden. Dieses Ziel wird in einer ugly iteration nur mit Mühe und in einer bad iteration gar nicht erreicht.

Der Übergang von einer good zu einer ugly iteration kann nicht am Burndown Chart abgelesen werden: Stillstand, der durch Nacharbeiten entsteht, wird u. U. durch den parallel dazu erreichten Projektfortschritt kaschiert. Hinzu kommt, dass die Teamgeschwindigkeit auch in good iterations schwankt; de facto funktioniert sie als Indikator nicht. Insofern verstehen wir unter einer hohen Teamgeschwindigkeit in einer good iteration, dass sie nicht nennenswert durch Nacharbeitungsaufwände verringert wird.

Als Indikator für den Übergang von einer good zu einer ugly iteration eignet sich aber das Qualitätsniveau gut, das z. B. über Anzahl und Schweregrad der Bugs genau genug ermittelt werden kann (Abb. 3).

Abb. 3: „Teamgeschwindigkeit“ und „Qualitätsniveau“ vs. „Anteil der Nacharbeitungsaufwände am Gesamtaufwand einer Iteration“
Geschrieben von
Jörn Koch und Sebastian Middeke
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.