Stabilisierung von havarierten, agilen Projekten

Von einer Havarie wird gesprochen, wenn ein Projekt massiv aus dem geplanten Zeit- und Kostenrahmen hinausläuft. Tritt diese Situation ein, gibt es drei Handlungsoptionen:

• Es wird so weitergemacht, wie es bisher der Fall war.
• Das Projekt wird abgebrochen.
• Es erfolgt eine Stabilisierung des Anforderungsrahmens und eine Anpassung der Projektabläufe.

Dieser Beitrag stellt die dritte Option in den Mittelpunkt. In diesem Kontext gehe ich von der Ausgangssituation aus, dass das agile Projekt bereits seit einiger Zeit läuft, aber noch über ein relevantes Restbudget beziehungsweise eine Restlaufzeit verfügt (mindestens 20% des ursprünglichen Projektumfangs). Weiterhin hat das Entwicklungsteam in unserem Beispiel bereits Erfahrungen mit den vorliegenden Umsystemen und den (vorgegebenen) Technologien gesammelt.

Das Vorgehen zur Stabilisierung

Die Umsetzung von Anforderungen wird zunächst gestoppt. Stattdessen wird eine Analysephase durchgeführt - im agilen Sprachgebrauch spricht man von einem „Analyse-Sprint“. Das Ziel dieses Sprints besteht darin, einen stabilen Rahmen zu schaffen, der die Grenzen der noch umzusetzenden Funktionalitäten beschreibt.

Konkret werden kleine Teams gebildet, die als Feature-Verantwortliche mit den Product Ownern sowie mit weiteren fachlichen Inputgebern intensiv die Anforderung analysieren. Idealerweise handelt es sich um gemischte Teams. Das bedeutet, hier bringen Developer, Testerinnen und Tester sowie Business-Analysten ihre jeweilige Perspektive in die Erhebung ein. Die Anforderungen werden so erhoben, dass Umsetzungsrisiken und Abgrenzungen ausgewiesen werden. Das Umsetzungsrisiko gibt ein technisches Risiko an, also zum Beispiel die Anbindung einer unbekannten Schnittstelle. Die Abgrenzung einer Funktionalität dient dazu, um aufwandstreibende Faktoren transparent darzustellen, damit diese explizit ausgeschlossen werden können. Wenn ein Feature komplett erhoben wurde, wird dieses mit einem Umsetzungsaufwand geschätzt, der auch den Aufwand für das Risiko beinhaltet.

Diese Art der Aufwandserhebung und -schätzung stellt sich für gewöhnlich als akkurat heraus, da das Umsetzungsteam aus den gewonnenen Erfahrungen vorangegangener Sprints schöpfen kann. Das Team kennt sowohl die Limitierungen der verwendeten Technologie sowie besonders aufwändige fachliche Anforderungen. Somit kann gezielt darauf hingearbeitet werden, besonders budgetbelastende Umsetzungsvarianten auszuschließen. Am Ende dieses intensiven Analyse-Sprints entsteht eine Liste an Anforderungen mit deren Gesamtaufwänden - inklusive des Risikoausweises.

In der sich anschließenden finalen Phase entscheidet der Product Owner – natürlich unter Beachtung des Gesamtbudgets, welche der erhobenen Anforderungen noch umgesetzt werden können. Hierbei hat es sich als „psychologisch“ vorteilhaft herausgestellt, mit einer leeren Liste anzufangen und Anforderungen hinzuzufügen. Im Alternativszenario werden verschiedene Punkte nach und nach von der kompletten Anforderungsliste gestrichen, was wiederum häufig zu Trennungsschmerzen bei den Entscheidern führt.

Zusätzlich kann ein paarweiser Vergleich der Funktionalitäten helfen, eine priorisierte Gesamtliste zu erstellen. Der Vorteil dieser Methode ist, dass pro Schritt jeweils immer nur zwei Anforderungen miteinander verglichen werden. Die komplette Liste setzt sich dann implizit als Ergebnis aller Einzelvergleiche zusammen. Auf diese Weise wird die Komplexität, die bei Mehrfachvergleichen auftritt, reduziert.

Der große Vorteil des Analyse-Sprints besteht darin, dass der bis dahin häufig fehlende Überblick geschaffen wird: Der gesamte Funktionsumfang wird sichtbar, Kosten für Funktionalitäten werden explizit ausgewiesen und es findet eine Priorisierung durch das vorgegebene Kostenbudget statt. Der Product Owner ist gezwungen, eine Priorisierung der Anforderungen anhand der Werttreiber der Software vorzunehmen. Am Ende steht schließlich ein Abnahmeprotokoll des neuen Funktionsumfangs, auf das sich alle Verantwortlichen verständigen.

Nach dem Analyse-Sprint wird die bisherige agile Arbeitsweise wieder aufgenommen, jedoch mit folgenden Unterschieden:

• Es werden keine Funktionalitäten umgesetzt, die nicht im Analyse-Sprint aufgenommen wurden.
• Die spätere inhaltliche Spezifikation von Anforderungen wird immer gegen die Abgrenzungen in der Anforderungsliste gehalten.
• Die angefallenen Umsetzungsaufwände werden konstant mit den geschätzten Anforderungen aus dem Analyse-Sprint verglichen. Bei Abweichungen wird eine Ursachenanalyse durchgeführt und gegebenenfalls werden weitere Anforderungen gestrichen.
• Das Change Management wird so gestaltet, dass nachträglich die Möglichkeit besteht, Anforderungen, wie oben beschrieben, innerhalb einer „Tauschbörse“ auszutauschen. Wichtig hierbei ist jedoch immer die Einhaltung des Gesamtkostenbudgets.

In dem hier skizzierten Eingriff wird die Flexibilität, die eine agile Softwareentwicklung mit sich bringt, massiv beschränkt. Der verbleibende Handlungsrahmen ist - insbesondere für den Product Owner - klar abgesteckt. Zusätzliche Iterationen zum Feinschliff oder Experimentieren werden auf ein Minimum beschränkt beziehungsweise ausgeschlossen. Änderungen am Projektumfang finden in einem klar definierten Change-Request-Prozess statt und ziehen Managementfreigaben und Budget-Diskussionen nach sich.

Fazit

Natürlich wird ein komplett havariertes Softwareentwicklungsprojekt am Ende kaum noch ein wirtschaftlicher Erfolg. Dennoch können euch die hier beschriebenen Maßnahmen dabei helfen, einen Projektabbruch zu vermeiden und somit noch ein fachlich sinnvolles Ergebnis für den User zu erreichen. Darüber hinaus können durch dieses Vorgehen Fehlvorstellungen und Probleme frühzeitig erkannt und eingedämmt werden.

Wenn ihr mehr zu spannenden Themen aus der adesso-Welt erfahren möchtet, dann werft auch einen Blick in unsere bisher erschienenen Blog-Beiträge.