Agile Selbstheilungsmechanismen

Bezüglich des Übergangs von einer ugly zu einer bad iteration verhält es sich genau umgekehrt: Das Qualitätsniveau ist in beiden Fällen niedrig und taugt daher nicht als Indikator. Die Teamgeschwindigkeit geht bei einer bad iteration jedoch gegen null.

Das Problem mit den beiden Indikatoren Teamgeschwindigkeit und Qualitätsniveau ist jedoch, dass wir darüber nicht feststellen können, ob wir aus einer ugly iteration wieder in eine good iteration gelangt sind: Das Qualitätsniveau kann hoch sein, wird aber durch kontinuierlich hohe Nacharbeitungsaufwände teuer erkauft. Damit ist die Teamgeschwindigkeit nicht so hoch, wie sie sein könnte. Wir benötigen also einen weiteren Indikator, um nicht unbemerkt in eine Phase von ugly iterations hineinzugleiten, die wir fälschlicherweise für good iterations halten. Dieser Indikator ist der Anteil der Aufwände, die für Nacharbeiten anfallen (Fehler rekonstruieren, lokalisieren, fixen sowie Nachtests), im Vergleich zu den Aufwänden, die für die eigentlichen geplanten Arbeiten anfallen (Entwicklung, Regressionstests, Abnahmetests). Die in agilen Projekten verwendeten Tools zum Tracking der Aufwände erlauben üblicherweise die separate Erfassung der Aufwände. Dies erfordert seitens des Teams jedoch Disziplin bei der Aufwandserfassung.

Bis zu einem gewissen Grad reichen die agilen „Selbstheilungsmechanismen“ aus, um den Übergang von einer ugly zu einer good iteration zu schaffen. Die Retrospektive ist z. B. ein wirkungsvolles Mittel, um Hindernisse im Prozess zu identifizieren und Maßnahmen zu beschließen, mit denen diese Hindernisse aus dem Weg geräumt werden. Unsere Beobachtung ist aber, dass die Ursachen für Qualitätsmängel häufig nicht explizit benannt werden können, da sie meist komplex und diffus sind. Besonders deutlich zeigt sich diese Schwierigkeit, wenn das niedrige Qualitätsniveau selbst der Grund für weitere Qualitätsmängel ist. Das ist z. B. dann der Fall, wenn neue Komponenten aus fehlerhaften Komponenten aufgebaut werden oder wenn „dunkle, unkontrollierbare Ecken“ im System verhindern, dass ein einwandfreier Entwurf exakt umgesetzt werden kann: Es ist schwierig, wenn nicht gar unmöglich, ein qualitativ mangelhaftes System qualitativ hochwertig weiterzuentwickeln!

In der Retrospektive zeigt sich das beispielsweise im Wunsch des Entwicklungsteams, Teile des Systems (die „dunklen Ecken“) durch Refactorings und qualitätssichernde Maßnahmen auf ein akzeptables Qualitätsniveau zu heben. Es ist jedoch wichtig, den Punkt bestimmen zu können, an dem der Aufwand für solche „Aufräumarbeiten“ größeren Stils gerechtfertigt ist, da es sich um nicht unmittelbar produktive Aufwände handelt. Wenn wir uns entschließen, in einer Iteration Aufwände vor allem in die Qualitätssteigerung zu investieren, handelt es sich um eine Verschiebung der Zielsetzung in der Iteration: Oberstes Ziel ist nicht mehr, ein weiteres (möglichst großes) product increment zu schaffen, sondern die Qualität so weit zu steigern, dass die QK des (möglicherweise kleinen) product increment erfolgreich verläuft.

Eine Iteration, die dies zum Ziel hat, nennen wir recovery iteration (Abb. 4).

Abb. 4: Die „Recovery Iteration“ als Weg zurück in die „Good Iteration“

Die Bewertung von Iterationen als „good“, „bad“ oder „ugly“ ist dabei ein sehr hilfreicher Ansatz, um zu bestimmen, wann es sinnvoll ist, eine oder mehrere recovery iteration(s) einzuschieben.

 

UGLY ITERATION

Im Allgemeinen ist die ugly iteration der vorherrschende Iterationstyp, wenn agil durchgeführte Projekte ihren Coachingbedarf signalisieren.

  • Der Anteil von Nacharbeiten an den Gesamtaufwänden ist auffällig und beeinflusst die Planung.
  • Stories werden aufgrund der Nacharbeiten oft nur unvollständig umgesetzt. Durch den hohen Anteil an work in progress am Ende einer Iteration steigt das Risiko weiterer Nacharbeiten.
  • Weder Teamgeschwindigkeit noch Qualitätsniveau sind beurteilbar, die Transparenz sinkt.
  • Leerlauf entsteht durch Wartezeiten auf Entwicklungs- und QK-Seite. Der Product Owner versucht häufig, diese mit neuen Stories zu füllen, und riskiert den work in progress-Anteil weiter zu erhöhen.
  • Bugs werden hauptsächlich von der QK gefunden, nicht von den Entwicklern.

Die ugly iteration begünstigt den weiteren Qualitätsverfall und erfordert aktives Gegensteuern.

 

GOOD ITERATION

Die good iteration ist das angestrebte Ideal und sollte gleichzeitig der Normalfall sein. Hier werden die gewünschten Ergebnisse in der geforderten Zeit und Qualität geliefert.

  • Stories werden innerhalb der Iteration abgeschlossen und die QK verläuft positiv.
  • Nacharbeiten finden nur im vernachlässigbaren Umfang statt.
  • Kein Stillstand durch Wartezeiten, die Tätigkeiten von Entwicklung und QK sind ineinander verzahnt: Die QK testet das jeweils letzte product increment und bereitet die Tests für das bereits in Entwicklung befindliche nächste product increment vor.
  • Diese Verzahnung von Entwicklung und QK ist sehr effizient, aber bei einem Absinken der Qualität schwer aufrechtzuerhalten. Dann droht die Gefahr, in „ugly iterations“ abzurutschen.

 

BAD ITERATION

Mit der Zeit entwickelt sich die ugly iteration zunehmend in Richtung einer „bad iteration“, wenn nicht gegengesteuert wird.

  • Das Team ist mit Nacharbeiten voll ausgelastet.
  • Ein durch die QK nachgewiesener Projektfortschritt ist aufgrund der hohen Nacharbeitungsaufwände und des niedrigen Qualitätsniveaus nicht mehr möglich.
  • Der Großteil der Tests schlägt fehl oder ist nicht mehr anwendbar. Im Extremfall kann die QK keine Tests mehr durchführen, da der Entwicklungsstand nicht mehr zu den Tests passt.
  • Anhäufen von technischer Schuld auf Entwicklungs- und Testschuld auf QK-Seite
  • Agile „Selbstheilungsmechanismen“ können den Projektzustand nicht mehr verändern. Aus eigener Kraft kann das Projekt nicht wieder „in die Spur kommen“.

 

RECOVERY ITERATION

Ein bewährter Weg aus „ugly“ und „bad iterations“ heraus besteht darin, den eingefahrenen Ablauf zu unterbrechen und den Prozess über eine oder mehrere „recovery iterations“ in die Spur zurückzubringen. Normalerweise erfordern „recovery iterations“ die Einwilligung von außen (Kunde/Management).

  • Das primäre Iterationsziel ist nicht mehr die Schaffung neuer Funktionalität, sondern die Anhebung des Qualitätsniveaus.
  • Entwicklung und QK laufen ohne Verzahnung und strikt sequenziell ab:
    • Entwicklung inkl. Tests auf Entwicklerseite
    • Test durch die QK
    • Im Fehlerfall: Erfassen des Bugs durch die QK
    • Bugfixing inkl. Nachtests auf Entwicklerseite
    • Nachtests durch die QK
  • Beide Seiten müssen sich auf die vorangegangenen Ergebnisse verlassen können, um ihrerseits eine hohe Qualität ihrer Ergebnisse garantieren zu können.
  • Die Durchführung von Aufräumarbeiten vermeidet Leerlauf, z. B. Refactoring von Code und Anheben der Unit-Testabdeckung auf Entwicklerseite sowie Reviews und Überarbeiten des Testdesigns auf QK-Seite.
  • Im Extremfall muss das System ohne Beteiligung der QK so weit „aufgeräumt“ werden, dass es testbar ist.

Die recovery iteration stoppt den Teufelskreis der ugly iteration unmittelbar. Die Qualität steigt in den bearbeiteten Bereichen kontinuierlich und (sofern die QK testen kann) nachweislich an. Das Projekt nimmt selbst aus einer bad iteration heraus wieder Fahrt auf. Die agilen „Selbstheilungsmechanismen“ können jetzt greifen, da Ziele und Hindernisse wieder klarer erkennbar sind.

Als Indikator zur Einstufung der Iterationen in good, bad und ugly verwenden wir – wie oben beschrieben – den Anteil der Nachbesserungsaufwände an den Gesamtaufwänden einer Iteration. Denselben Indikator verwenden wir, um abzuwägen, wann wir die (zeitaufwendigen) „recovery iterations“ wieder absetzen.

Beispiele aus der Praxis

In der Praxis setzen wir die Einstufung von Iterationen in „good“, „bad“ und „ugly“ seit knapp zwei Jahren in teils sehr unterschiedlichen Projekten ein (auch wenn wir oft andere Namen dafür verwendet haben, z. B. „failed sign-off/no progress“ statt „ugly/bad“ oder „Aufräum-Iteration“ statt „recovery iteration“).

Das Feedback aus den verschiedenen Teams macht deutlich, dass die unmissverständliche Einstufung der Iterationen in good, bad und ugly eine offenbar hilfreiche Orientierung bietet, und das sowohl bei der Einschätzung des Projektzustands als auch der Faktoren, die zu diesem Zustand geführt haben.

Die „recovery iterations“ haben wir mehrfach gezielt einsetzen können, um Projekte wieder in die Spur zu bringen, die teils sehr große Schwierigkeiten mit dem agilen Vorgehen hatten.

Darüber hinaus gewährt die Einstufung der Iterationen einen einfachen und dennoch informativen Überblick über den iterativen Projektverlauf – z. B. für das Reporting gegenüber dem Management. Dies ist in den folgenden beiden, sehr unterschiedlichen Beispielen zu sehen, mit denen wir versuchen, einen knappen Eindruck von der Bandbreite von Projekten zu geben, in denen unser Ansatz anwendbar ist.

 

PROJEKT A

  • Projektziel: Schaffung einer technischen Basis zur Synchronisation von Informationen zwischen verschiedenen Projekten
  • Laufzeit: ca. 5 Monate
  • Status: kurz vor Abschluss
  • Teamgröße: 2 – 3 Entwickler, 1 QKler
  • Vorgehensmodell: iterativ-inkrementell, angelehnt an Scrum; zweiwöchige Iterationen
  • Beginn unseres Coachings: mit Projektbeginn

 

Das Projektteam besaß nur wenig Erfahrung mit agilen Vorgehensweisen und hatte anfangs Probleme, agile Techniken und das Projekt-Tracking konsequent anzuwenden. Unklar formulierte Anforderungen erforderten zahlreiche Nachfragen beim Anforderungsgeber und erschwerten die Situation aus Sicht des Teams noch weiter.

Nach einem hoffnungsvollen Start folgte eine Reihe von ugly iterations. Eine Trendumkehr mithilfe agiler „Selbstheilungsmechanismen“ schien uns angesichts des unerfahrenen Teams nicht in Sicht, so dass wir uns entschlossen, eine recovery iteration einzuschieben, um den Negativtrend zu stoppen. Eine einzelne recovery iteration reichte aus, um dem Team wieder Übersicht über den Prozess zu geben, so dass in der Folge mit begleitendem Coaching wieder „good iterations“ gelangen (Abb. 5, Projekt A).

Abb. 5: Projektverlauf der Beispiele
Kommentare

Schreibe einen Kommentar

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