Responding to change over following a plan does not imply not having a plan

Bild: Startup Stock Photos - CC0 1.0

Ein wunderbares Zitat, gefunden im Blog von Steve McConnel. Wunderbar deshalb weil es auf einen der beliebtesten (Pseudo)Kritikpunkte an Scrum und/oder Agile eingeht, der da lautet, dass in diesen Methodiken nicht geplant wird. Das Gegenteil ist richtig, was auch einfach zu erklären ist: ohne einen (ursprünglichen) Plan gehabt zu haben ist "responding to Change" unmöglich, denn dieses bedeutet ja nichts anderes als den (mittlerweile als ineffizient erkannten) Ursprungsplan so an die mittlerweile gewonnenen Ergebnisse anzupassen, dass er erneut die beste erkennbare Lösung darstellt - so lange bis weitere Erkenntnisse weitere Anpassungen und Optimierungen ermöglichen.


Agile Prozesse haben damit nicht nur einen Plan als Eingangs- und Ausgangswert - im Grunde ist der gesamte agile Prozess nichts weiter als ein einziger fortlaufender Planungsvorgang. Hier liegt auch der zentrale Unterschied zum klassischen Projektmanagement (PMP, Prince2 und Ähnliche) in dem zu Beginn ein Plan festgelegt wird, an den sich dann theoretisch alle zu halten haben.¹

Das üblicherweise an dieser Stelle auftretende Gegenargument ist, dass ein solcher Plan (sowohl im ursprünglichen als auch im fortgeschrittenen Status) völlig mangelhaft sein muss, sonst müsste er schließlich nicht permanent geändert werden. Ein scheinbar schlagender Punkt, allerdings wirklich nur scheinbar. Denn: Zum Zeitpunkt jeder Anpassung ist das Ergebnis lediglich der in diesem Moment und auf Basis der in diesem Moment verfügbaren Informationen beste Plan. Sobald sich diese Informationen ändern ist er es nicht mehr und muss erneut angepasst werden. Erneut ein übliches Gegenargument: Wenn man denn am Anfang länger/besser geplant hätte, dann wäre auch der Plan besser, man müsste ihn nicht so oft anpassen und man wäre schneller fertig. Tatsächlich ist das sogar eine relativ häufige (und relativ verheerende) Manager-Ansicht. Im besten Fall führt sie zum unsanften Erwachen durch Konfrontation mit der bösen Realität, die sich einfach nicht an den schönen Plan halten will, im schlimmsten Fall wird die offensichtliche Unbrauchbarkeit des Plans geleugnet und das Team gezwungen eine vergleichsweise schlechte Lösung umzusetzen.

Der Normalfall liegt irgendwo dazwischen. Am Anfang steht ein angeblich präziser, in Wirklichkeit aber "hinreichend unscharf" formulierter Plan. Sobald der sich als unrealistisch herausstellt werden mit vollen Händen geplante Features über Bord geworfen, wobei bevorzugt die genommen werden "die man nicht sieht" (Qualitätssicherung, Dokumentation, Unit-Tests, einheitliche Architektur, etc.). Das Ergebnis ist ein Produkt das von Außen halbwegs ansehnlich aussieht, bei dem unter der Haube Kraut und Rüben durcheinanderliegen und über das man dem Kunden gegenüber behauptet, genau so wäre es von Anfang an geplant gewesen. Ein paar Releases bekommt man auf diese Weise sogar hin, bis das vermurkste Produkt unter der Last seiner technischen Schulden kollabiert und weggeworfen werden muss (habe ich so schon erlebt).

Der scrum-/agile Idealfall (gibt es da einen Normalfall?) ist anders. Zu Beginn lassen sich auch hier Rahmenbedingungen setzen, sei es finanzieller oder zeitlicher Art, danach geht die Entwicklung los, die immer das kleinstmögliche funktionierende Ergebnis (minimum viable product) zum Ziel hat. Sobald das erreicht ist kann auf Basis der verbleibenden Zeit und Ressourcen neu geplant werden, und zwar je nach Kundenwunsch durch Zusatzfeatures zum bisherigen Funktionsumfang oder komplett neue Funktionen. Und da in jedem Sprint durch die Definition of Done auch (Unit)Tests und (Code)Dokumentation erstellt werden müssen kommt es auch nicht zum Auftürmen technischer Schulden.² Es gibt zwar angeblich agile Projekte in denen das nicht so läuft, aber die meisten davon sind, wie ein Bekannter letzte Woche meinte, "not even Cargo Cult".

¹Die üblicherweise im Projektverlauf auftretende Häufung von Change Requests, Fast Tracking und ähnlichen Unsitten ist im Regelfall eher chaotisch als agil.
²Ja, man kann das auch weglassen. Dann ist es aber nicht Scrum oder Agile sondern Murks.