Agile Selbstheilungsmechanismen

Die Teamgeschwindigkeit ist im Vergleich zu erfahrenen Teams auch in den good iterations etwas niedriger. Dennoch erreicht auch das agil unerfahrene und auf das Coaching angewiesene Team einen angemessenen und kontinuierlichen Projektfortschritt mit stimmiger Qualität.

Zurzeit befindet sich das Projekt in der Endphase. Ein erfolgreicher Abschluss des Projekts erscheint aus momentaner Sicht sehr wahrscheinlich.

 

PROJEKT B

  • Projektziel: Ablösung einer klassischen Webanwendung durch eine moderne Rich Internet Application – für einen sehr großen Kundenkreis
  • Laufzeit: mind. 3 Jahre; „Neustart“ des Projekts nach ca. einem Jahr
  • Status: in der Umsetzung
  • Teamgröße: ca. 10 Entwickler (vor Neustart ca. 30), ca. 5 QKler
  • Vorgehensmodell: Scrum, Begleitung durch Scrum-Coaches; anfangs vierwöchige Iterationen, nach Beginn des Coachings zweiwöchig
  • Beginn unseres Coachings: ca. ein Jahr nach Projektbeginn, zum Neustart intensiviert

 

Das Projektteam besaß zu Beginn unseres Coachings bereits einige Erfahrung mit der agilen Vorgehensweise. Die agilen Techniken waren allen bekannt und wurden teils minutiös angewandt. Retrospektiven wurden regelmäßig durchgeführt. Die QK besaß eine umfangreiche Datenbank mit detaillierten Tests. Bugs wurden von der QK dokumentiert, bewertet und verfolgt.

So weit, so ideal – doch das Qualitätsniveau der realisierten Anwendung passte nicht zu diesem Bild: Prototypische, halbfertige und fehlerhafte Teile durchmischten sich untrennbar mit angeblich funktionierenden Teilen. Die QK konnte zahlreiche Tests gar nicht anwenden oder stieß bei deren Durchführung auf Fehler. Einige auffällige Bugs existierten bereits seit mehreren Iterationen und wurden nicht behoben, da die Umsetzung weiterer Stories eine höhere Priorität hatte – ein Versuch, den Projektstillstand durch „Gasgeben“ abzuwenden.

De facto war jedoch schon seit längerem kein Projektfortschritt mehr durch die QK nachweisbar und wurde schließlich auch vom Auftraggeber nicht mehr erkannt. Diese Situation hat schließlich das Management dazu bewogen, einen „Neustart“ des Projekts durchzuführen (siehe Grafik 5, Projekt B).

Die Iterationen vor dem Neustart ließen sich auch im Nachhinein klar als bad iterations ausweisen. Mit dem Neustart bekamen wir die Chance, recovery iterations einzuführen, um darüber die Kontrolle über den Prozess zurückzuerlangen.

In diesen recovery iterations hat das Entwicklungsteam das System massiv überarbeitet, Halbfertiges und Prototypisches ersatzlos ausgebaut und konsequent Fehler behoben – so lange, bis die QK schließlich nach einer „Aufräumphase“ von fast zwei Monaten zum ersten Mal einen vollständigen, erfolgreichen Regressionstest des gesamten Systems durchführen konnte.

Neben der deutlichen Qualitätsverbesserung des Systems waren die „recovery iterations“ für das Entwicklungsteam sehr wichtig, um schließlich ein hohes Qualitätsverständnis in der Praxis etablieren zu können, das den technischen Fähigkeiten des Teams entsprach.

Die QK hatten wir während der „recovery iterations“ größtenteils aussetzen müssen, da keine aussagekräftigen Tests durchführbar waren. Die QK nutzte diese Zeit, um ihre Tests zu sichten und an den Scope des „aufgeräumten“ Systems anzupassen. Mit den ersten erfolgreich durchgeführten Regressionstestfällen konnte die QK ihre reguläre Arbeit schließlich wieder aufnehmen.

Auf Basis des „aufgeräumten“ Systems griffen auch wieder agile „Selbstheilungsmechanismen“, deren Effekt zuvor verpufft war.

Inzwischen rutscht das Team nur noch selten in ugly iterations ab und findet in solchen Fällen aus eigener Kraft wieder heraus. Die Teamgeschwindigkeit hat mittlerweile ein hohes Niveau erreicht – Entwicklung und QK arbeiten parallel. Nacharbeiten und Nachtests spielen keine nennenswerte Rolle mehr, die Planungssicherheit ist dementsprechend hoch.

Fazit

Eine hohe Qualität der implementierten Software ist für den Projekterfolg notwendig, sie kann aber – wie wir in vielen Projekten erleben – nicht immer erreicht und gehalten werden.

Die Gründe für den Qualitätsverlust sind meist komplex und schwer zu benennen. Agile „Selbstheilungsmechanismen“ wie die Retrospektive sind zwar hilfreich und notwendig, reichen aber in vielen Fällen nicht aus oder greifen unterhalb eines gewissen Qualitätsniveaus gar nicht mehr.

Über die Indikatoren Teamgeschwindigkeit, Qualitätsniveau und den Anteil der Nacharbeitungsaufwände am Gesamtaufwand können wir drei Typen von Iterationen identifizieren: „good“, „bad“ und „ugly iterations“. Diese helfen uns, Transparenz über den Projektzustand herzustellen und zu entscheiden, ab wann und bis wann umfassende qualitätsverbessernde Aufwände gerechtfertigt sind.

Zur Qualitätsverbesserung haben sich „recovery iterations“ bewährt, in denen wir die Zielsetzung vom Umsetzen neuer Anforderungen auf die Anhebung des Qualitätsniveaus verschieben. Dies ist ein sehr wirkungsvoller Mechanismus, über den ein „aus der Spur gekommener“ agiler Prozess wieder korrigiert werden kann.

Jörn Koch ist Senior Software-Architekt bei der C1 WPS GmbH. Er leitet und coacht seit 2001 agile Projekte und besitzt langjährige Erfahrung in der Einführung und im „Tuning“ agiler Prozesse. Kontakt: Joern.Koch@c1-wps.de

Sebastian Middeke ist Senior Software-Qualitätsmanager bei der C1 WPS GmbH. Er coacht seit 2005 agile Projekte und begleitet die unternehmensweite Einführung agiler Prozesse. Kontakt: Sebastian.Middeke@c1-wps.de

Kommentare

Schreibe einen Kommentar

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