Man ist nicht agil … mit einem agilen Wasserfall

Viele Organisationen bezeichnen sich selbst als agil. Wer würde nicht agil sein wollen? Wenn man nicht agil ist, ist man dann nicht per definitionem schwerfällig, langsam und träge?

Nur wenige Organisationen würden sich so bezeichnen; allerdings bedeutet Agile in der Welt der Softwareentwicklung, -verbesserung und -wartung mehr, als schnell und leicht agieren zu können. Agile bedeutet, dass ein Team oder eine Organisation gewisse Prinzipien annimmt, die Verhaltensweisen prägen und zum Verinnerlichen bestimmter Methoden führen.

Wenn nicht so gehandelt wird, wie es behauptet wird, steht das Management häufig den Prinzipien im Weg und die Praktiker den Methoden. Die Methoden in Organisationen sind oft sehr festgefahren und erfordern einen erheblichen Änderungsaufwand. Einige Organisationen behaupten, einen gemischten Ansatz zu nutzen und von einem eher klassischen Ansatz zu einer Kombination aus Scrum, Kanban und Extreme Programming überzugehen. Das wird als sicherer und konservativer Ansatz angesehen, der es einer Organisation erlaubt, sich organisch zu verändern. Das Problem dabei ist jedoch, dass diese Taktik selten funktioniert und sich die Organisationen schnell festfahren. Wenn man nicht genug Zeit und Mühe in das Änderungsmanagement investiert, führt das schnell zu Hybrid-Frameworks, die weder Fisch noch Fleisch sind – und die sind nur äußerst selten agil.

Kennzeichen für festgefahrene (oder potentiell festgefahrene) Organisationen

Der iterative Wasserfall:

Der klassische iterative Wasserfall hat seine Wurzeln im Spiralmodell von Barry W. Boehm. In dieser Pseudoversion der iterativen Entwicklung werden kurze und zeitlich begrenzte Iterationen für jede der klassischen Wasserfallphasen eingesetzt. Auf einen Anforderungssprint folgt ein Designsprint, dann ein Entwicklungssprint usw. Sowohl das klassische Spiralmodell als auch die Pseudoversion von Agile eignen sich trotzdem wesentlich besser als das klassische Wasserfallmodell dafür, Feedback zu generieren und schneller Werte zu liefern; allerdings hören die Organisationen daher aber auf, sich weiter in Richtung Agile zu entwickeln und ernten somit nur einen Teil der Früchte.

Anforderungen im Vorfeld festlegen:

Bei diesem Hybridansatz für Agile sammeln Teams oder Organisationen alle Anforderungen (manchmal Features genannt) zu Anfang des Projekts und legen sie fest, bevor die tatsächliche Arbeit beginnt. Agile basiert auf gewissen Annahmen bezüglich der Anforderungen. Zwei der Hauptannahmen sind, dass Anforderungen immer wieder neu auftauchen und dass sie – sobald sie bekannt sind – mit der Zeit wieder verschwinden. Es ist ein Widerspruch zu diesen beiden Annahmen, wenn man Product Backlogs vorab festlegt. Außerdem wirft es die Teams und Organisationen zurück in eine Zeit, in der Lösungen entwickelt wurden, die am Ende nicht den aktuellen Geschäftsanforderungen entsprechen. Diesen Ansatz gibt es meistens, wenn die Einführung von Agile mit einem gestaffelten Ansatz durchgeführt wird, bei dem man mit den Entwicklern anfängt und dann später die Business Analysts usw. miteinbezieht. Zwischen den Gruppen, die Agile verinnerlicht haben, und solchen, bei denen das nicht der Fall ist, kann oft zusätzliche Reibung entstehen, was häufig den agilen Methoden zur Last gelegt wird und so weitere Veränderungen erschwert.

Testen, nachdem die Entwicklung „done” ist:

Eine der gefährlichsten agilen Mischformen ist das Testen nach der abgeschlossenen Entwicklung. Diese Hybridform habe ich schon unter dem Namen „Entwicklung + 1 Sprint” kennengelernt. In diesem Szenario entwickelt ein Team eine Lösung (funktionierender Code bei einem Softwareproblem), demonstriert es den Kunden, behauptet es sei „done” und gibt es DANN an die Tester weiter. Tester finden IMMER etwas. Darum wird die Software wieder zurück gegeben, damit man entweder direkt daran arbeiten kann (was den aktuellen Sprint unterbricht) oder das Ganze in den Backlog verschieben kann, um sich später darum zu kümmern. Die agilen Prinzipien unterstützen die Fertigstellung auslieferbarer (oder zumindest potentiell auslieferbarer) Software zu Ende jedes einzelnen Sprints. Auslieferbar bedeutet GETESTET. Zwei nicht ganz so dramatische Varianten dieses Problems sind die Nutzung von Hardening Sprints und das Testen ganz am Ende eines Projekts. Immerhin wird in diesen Fällen nicht behauptet, man sei agil.

Fazit zu agile und Wasserfall

Die Art und Weise, wie Leute arbeiten, ist der einzig sichere Indikator dafür, ob eine Organisation agil ist oder nicht. Manchmal spiegelt die Arbeitsweise dieser Personen einen Wechsel zu Agile wider – jedoch gehe ich davon aus, dass man sich dort bald festfahren wird, wenn dieser Wechsel nicht mit großem Eifer durchgeführt wird. Wenn ein Team oder eine Organisation Agile übernehmen wollen, wählt man ein Projekt aus und lässt alle, die in dieses Projekt involviert sind, gleichzeitig und während des gesamten Arbeitsablaufes mit Agile arbeiten. Wenn das bedeutet, dass man ein ganzes Projekt oder ein ganzes Team coachen muss, dann ist das eben so. Diesen Ansatz kann man gut mit einer Zwiebel vergleichen, die man in Scheiben schneidet und bei der man bei jedem Schnitt jede einzelne Lage der Zwiebel erreicht, anstatt Lage um Lage abzuschälen.

Eine letzte Anmerkung: Auch wenn man mit diesen Hybridansätzen irgendwann an seine Grenzen kommt, sind sie wahrscheinlich immer noch besser als die Methode(n), die man zuvor genutzt hat. Das hier soll keine Anklageschrift an die Leute sein, die Probleme damit haben, zu Agile zu wechseln. Es soll vielmehr ein Anstoß für sie sein, weiterzumachen.

Dieser Text stammt aus dem Blog von SPamCAST und wurde von uns ins Deutsche übersetzt.