Agiles und klassisches Projektmanagement I – Planung

Agilität ist mehr als ein neuer Ansatz oder eine neue Methode Projekte zu managen. Es ist eine Arbeitsweise bzw. eine Wertevorstellung. Die Punkte des agilen Manifests zeigen es auf:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Entgegen landläufigen Vorurteilen handelt es sich nicht um Aussagen, die etwas negieren. Es wird nicht gesagt, es müsse keinen Plan oder keine Dokumentation geben. Es sind Werte und Prioritäten. Es wird mehr Wert auf die Lauffähigkeit der Software – oder allgemeiner die Funktionstüchtigkeits des Projekt-Ziel-Artefakts – gelegt, als auf eine ausführliche Dokumentation. Es wird in Bezug auf den Kunden mehr Wert auf Zusammenarbeit als Vertragsverhandlung gelegt. Auch im ersten und im letzten Punkt sind Prioritäten formuliert. Diese lohnen aber eine genauere Betrachtung, da hier große Differenzen zum klassischen Projektmanagement sichtbar werden. Trotz der Differenzen steckt in den Punkten „Individuals und Interactions“ bzw „Responding to change“ auch der Schlüssel zur Kombination agiler und klassischer Vorgehensweisen.

Responding to change over following a plan

In agilen Projekten wird nicht geplant – so lautet eines der Vorurteile. In agilen Projekten gibt es sehr wohl einen Plan, er hat lediglich eine geringere Reichweite und wird sehr häufig überarbeitet und schrittweise verfeinert. Im Falle von Scrum wird täglich geplant und täglich geprüft ob der Plan eingehalten wurde. Jede(r) formuliert täglich die nächsten Aufgaben, die er oder sie in Angriff nimmt. Beim nächsten Meeting wird über die Erledigung oder Nicht-Erledigung gesprochen. Die Aufgaben wurden zuvor bei der Planung des jeweiligen Sprints gemeinsam ermittelt. Die Aufgaben selbst leiten sich aus den Anforderungen, die in diesem Sprint umgesetzt werden sollen, ab. Die Anforderungen wiederum entstammen dem priorisierten Produkt-Backlog. Es handelt sich also um eine verschachtelte Struktur von Plänen, die iterativ verfeinert werden. In einem „Wasserfall“-Projekt wird zu Beginn ein Gesamtplan erstellt, der so gut wie möglich eingehalten wird. Die Grafik zeigt den Unterschied:

Die real zu erledigenden Aufgaben (graue Balken) werden klassisch so früh und so vollständig wie möglich ermittelt und geplant. Im agilen Projekt werden zu Beginn die Eckpfeiler des Projektes (Vision und Endtermin) und der Plan für den ersten Sprint festgelegt. Die weitere Spezifikations- und Planungsarbeit wird über das Projekt verteilt. Die Planungsarbeit liegt klassisch überwiegend beim Projektleiter. In agilen Projekten beteiligt sich das Team wesentlich stärker an der Planung. Der Unterschied der Planung liegt also überwiegend darin „Wann und von wem der Plan gemacht wird“. Eine mögliche Synthese von klassischer und agiler Vorgehensweise ist in der nächsten Grafik angedeutet:

Ein grob ausgeführter Wasserfall liefert den Input für den Start der agilen Implementierung, die agile Implementierung liefert das Produkt zurück. Der klassische Grobplan ist der Rahmen in dem die agile Detail-Planung ablaufen kann. Am Thema Planung wird einerseits die Differenz der Ansätze aber auch ein möglicher Synthese-Punkt sichtbar.

Und hier geht es zum zweiten wichtigen Unterschied zwischem agilen und klassischer Vorgehensweise.