Macht ein Plan agil?
Pläne sind in agilen Projekten manchmal unbeliebt. Schon öfter habe ich gehört: „Wir brauchen keinen Plan, wir haben unseren Backlog.“ Diese Abneigung gegen Pläne ist zu verstehen, wenn man sich an die ausgefeilten und strengen Vorgehensmodelle erinnert, die vor Jahren üblich waren. Sie führten dazu, dass zahlreiche Entscheidungen zu früh gefällt wurden. Die Folge: es wurde vieles entwickelt, was für die spätere Nutzung unnötig oder sogar störend war. Lag dies an den Plänen? Oder lag es daran, wie man mit den Plänen umgegangen ist?
Bei Plänen muss man grundsätzlich unterscheiden zwischen Projektplänen und Bauplänen. Projektpläne zeigen, wie man in einem Projekt vorgehen möchte. In ihnen findet man Termine und die Einplanung von Ressourcen. Baupläne beschreiben, was im Projekt erstellt oder umgebaut wird.
Ob Pläne agil machen oder die Agilität einschränken hängt davon ab, wie man sie verwendet. Wird ein Plan detailliert als streng einzuhaltende Vorgabe verwendet, lässt er natürlich nicht viel Platz für Agilität. Dies erfordert allerdings auch, dass man bei der Erstellung des Plans detaillierte Entscheidungen fällt, was eine enorme Sorgfalt und Weitsicht erfordert. Im technischen Bereich ist dies häufig unumgänglich. Man denke an eine Steuerung in einem Auto oder in einem Flugzeug. Hier sind detaillierte Spezifikationen (mit Plänen) unerlässlich.
Im Bereich der Geschäftsanwendungen ist es jedoch häufig schwer, alle Anforderungen an eine Lösung bereits am Anfang festzulegen. Meist ist es auch nicht nötig. Deshalb sind hier agilen Methoden wie z.B. Scrum immer häufiger anzutreffen. Bedeutet dies in der Schlussfolgerung, dass man keine Pläne erstellen kann, weil viele Entscheidungen noch offen sind?
Ich bin der festen Überzeugung: doch! Das geht nicht nur, das ist sogar dringend nötig. Der Plan ist jedoch nicht als strenge Vorgabe zu sehen, an die man sich strikt halten muss. Der Plan führt die aktuellen Vorstellungen in den Teams zusammen und macht sie sichtbar. Der Plan hilft, über Ideen zu reden und die individuellen Sichtweisen zu synchronisieren. Er ist ein Kommunikationsmittel.
Bei neuen Erkenntnissen hilft der Plan schnell und zielgerichtet zu reagieren. Er hilft zu erkennen, welche Stellen betroffen sind. Bei Bedarf wird der Plan angepasst. Änderungen werden besser verstanden und nachvollzogen. Zusätzlich gibt er den Teams Orientierung bei den zahlreichen „Mikroentscheidungen“, die tagtäglich zu treffen sind. Diese werden weniger durch die unterschiedlichen Verständnisse der Beteiligten behindern und verzögert.
Ganz wichtig dabei: der Plan zeigt immer den aktuellen Stand der Erkenntnis. Wenn sich neue Erkenntnisse ergeben, ist es der Plan anzupassen. Der Plan entwickelt sich im Laufe des Projektes immer weiter.
Wird ein Plan in diesem Sinne verwendet, macht er Teams wirklich agil. Probieren Sie es einfach aus.
Eine kleine Ergänzung: Dieser Artikel soll nicht den Eindruck erwecken, dass die „Agile Community“ grundsätzlich gegen Pläne und Dokumentation ist.
In dem Buch „Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge“ von Opelt, Gloger, Pfarl und Mittermayr (Hansa Verlag, 2012) habe ich folgendes gefunden:
„Natürlich gibt es Dokumente, die wir alle für sinnvoll halten, die notwendig sind. Ein Arztbrief ist zum Beispiel nötig, damit im Krankenhaus alle wissen, wie man einen Patienten behandeln muss. Die Baupläne eines Architekten sind wichtig, weil sich daran die Arbeit auf einer Großbaustelle ausrichtet. … Was will uns dieser Satz des Agil Manifesto sagen? Am Ende darf der Projekterfolg nicht daran gemessen werden, ob der Bauplan erstellt wurde … Das Dokument ist nicht das Produkt. Also misst sich auch der Projekterfolg nicht daran, ob die laut Prozess korrekten Dokumente geschrieben wurden.“
Dokumentation und Baupläne müssen dazu beitragen, die Projektziele zu erreichen. Wenn sie zum Selbstzweck werden, kann man sich den Aufwand sparen.