Rolling Wave Planning (RWP) gleich agil? Natürlich, was denn sonst? Schon der PmBok Guide 3th aus dem Jahr 2004 kannte agiles PM. Allerdings unter dem Namen „Rolling Wave Planning“. Zu gut deutsch „Rollierende Wellen Planung“. In den deutschen Übersetzungen immer als „Rollierende Planung“ bezeichnet. Wobei dies die eigentliche Vorgehensweise nicht wirklich beschreibt. „Rollierend“, beschreibt eine Tätigkeit auf der Stelle tretend, also nur Iteration, ohne Fortschritt. „Rollierende Wellen Planung“ dagegen, beschreibt beides, „Fortschritt und Iteration“.
Eine Welle bewegt sich nach vorn, die Welle in sich erzeugt Iterationen. Sehr schön auf dem 2. Bild auf dieser Website zu sehen.
RWP hat nichts mit „Wasserfall“ zu tun, kann aber im Rahmen eines Wasserfall Entwicklungsansatzes angewendet werden. Quasi ein moderner Vorläufer der hybriden Entwicklungsansätze.
Ob RWP schon in den PmBok Guides 1 + 2 enthalten war, kann ich nicht sagen. Falls ein Leser den Nachweis erbringen kann, freue ich mich über einen Kommentar. Allerdings fand RWP seit der Version 3 in jedem PmBok Guide Berücksichtigung und galt auch immer als Teil der PMP Prüfung.
Ken und Jeff haben diese Methode sicherlich entdeckt und anschließend verfeinert. Iterationen waren ja, wie weiter oben aufgezeigt, im RWP schon enthalten. Der Text beschreibt auch sehr ausführlich, wie RWP zu funktionieren hat. Alle unbekannten Arbeitsinhalte, in weiter hinter liegenden Perioden, sollten davon betroffen sein. Zumindest dann, wenn die Anforderungen unklar waren oder die Expertise noch fehlte.
*Work Brake Down Structure
Rolling Wave Planning im Projektstrukturplan.
Das RWP wurde dann auch im Projektstrukturplan (PSP/WBS*) berücksichtigt. Hier gab es und gibt es neben Liefergegenständen auf der höchsten Ebene, sowie heruntergebrochen auf darunterliegenden Ebenen (Baumstruktur), Arbeitspakete, Kontrollkonten, und ganz wichtig in diesem Kontext: Planungspakete!
Planungspakete stellen quasi Platzhalter dar, die für die noch unbekannten Anforderungen und Expertisen im PSP unterhalb der Kontrollkonten platziert werden. So kann man zumindest grob Aufwand und Kosten schätzen, die auf keinen Fall bei Null liegen können. Im Kontrollkonto werden alle darunterliegenden Arbeitspakete und Planungspakete subsummiert. Alle Kontrollkonten ergeben die Performance Measurement Baseline des Projektmanagers…..wobei es da noch ein paar andere Aspekte gibt. Eine alternative Vorgehensweise wäre, alle Planungspakete unter einem Kontrollkonto zusammen zu fassen. Das hat den Vorteil, dass diese geschätzten Kosten und Aufwände insgesamt, noch als sehr fragil oder konzeptionell deklariert werden können.
In der Version 6th als auch auf der PMIstandards+ wird Rolling Wave Planning folgendermaßen kommentiert: „It is a form of progressive elaboration applicable to work packages, planning packages, and release planning when using an agile or waterfall approach.“
Hier wird jetzt der agile Kontext zum ersten Mal explizit beschrieben.
Auch SCRUM kennt Analogien zum Planungspaket. Auf einem Burndown-Diagramm werden auf der X-Achse die Anzahl der Sprints angezeigt. Auf der Y-Achse die Aufwände oder Story Points. Beispiele in verschiedenen agilen BLOGS bilden dort um die 10 Sprints auf der X-Achse ab. Bei der Dauer von zwei Wochen also eine Prognose von etwa 20 Wochen. So ganz ohne horizontale Perspektive geht es auch im agilen Projektmanagement nicht. Allerdings legt man keine Deadline fest.
Da alle Sprints nach dem ersten Sprint, inhaltlich nicht geplant werden, entsprechen sie analog den Planungspaketen aus dem prognostizierenden Projektmanagement. Interessant ist auch, dass der Begriff „prognostiziert“ häufig in agilen BLOGS auftaucht.
Daher versucht man sich vom prognostizierenden Projektmanagement mit dem Begriff „klassisches Projektmanagement“ abzugrenzen. Obwohl es sich bei allen Szenarien des PmBok Guides, eindeutig um Prognosen handelt und nicht um etwas „Klassisches“. Ich kann es nicht oft genug sagen: „Der PmBok Guide verwendet nicht einziges Mal den Begriff „klassisches Projektmanagement“!
Rolling Wave Planning wurde vernachlässigt!
Genau genommen läuft PMI sich selbst hinterher! RWP oder agiles PM, war schon immer ein Thema in den PmBok Guides. Man hatte es versäumt, ein echtes Konzept daraus zu entwickeln. Im PmBok Guide 3th erfolgte ein sehr guter Ansatz, der aber in den folgenden Versionen nicht vertieft wurde. Erst Ken und Jeff bastelten ein Konzept, das das PMI wiederum inspirierte, mit der Version 6 die agilen Methoden stärker in den Fokus zu nehmen. Auch die PMP Prüfung enthält jetzt 50% agile Fragen. Die Version 7 wird in diesem Jahr agiles PM ebenfalls weiter vertiefen.
Allerdings ist der Lernstoff der agilen Inhalte im Vergleich zu den Werkzeugen und Methoden des bisherigen PmBok Guides als marginal zu bezeichnen. Schließlich sind die meisten Werkzeuge und Methoden (Stichwort SCRUMBUTS) nach wie vor auch für das agile PM von Interesse und gültig. Oder es existieren sehr viele Ähnlichkeiten im agilen PM, mit Werkzeugen und Methoden, die schon seit Jahrzehnten im PmBok Guide existieren. Beispiel: Meilenstein Trendanalyse (MT) und Burndown-Diagramm. Wer die Meilenstein Trendanalyse verstanden hat, versteht auch sehr schnell das Burndown-Diagramm. Man verlegt die Ankathete (Berichtszeitpunkte in der MT) einfach wieder auf die untere Ebene, lässt die Hypotenuse beiseite, und schon kann man ein Burndown-Diagramm daraus basteln.
Man kann also durchaus folgende Entwicklung des agilen PM beschreiben:
Der PmBok Guide legte den Grundstein mit dem Rolling Wave Planning. Agilisten erkannten die Sinnhaltigkeit des RWP, aber auch das fehlende Konzept. PMI erkannte den Sinn des Konzepts der Agilisten und schusterte eine Symbiose, die den Frame mit dem robusten, vertikale Fundament verband.
