Agile PM in großen T&T Projekten

Agile und Wasserfall Methodik scheinen auf den ersten Blick wie Feuer und Eis. Das passt doch gar nicht zusammen. Seit einigen Jahren interessiere ich mich für agiles Projektmanagement und habe mich immer schon gefragt wie die Anwendung dieser Methode in großen langlaufenden Projekten nutzbar sein kann. Ich glaube, und so ist auch wohl der Tenor der Projektmanagement community, ein Kompromiss oder die Wahrheit liegt in der Mitte scheint ein vertretbarer Ansatz zu sein. Die spannende Frage dabei ist, wie denn ein solcher Kompromiss ausschaut? Wie verzahnt sich agiles Projektmanagement mit klassischer Wasserfall Methodik, wo sind die Schnittstellen, wo sind die Grenzen, wo kommt man eigentlich um agiles Projektmanagement überhaupt nicht drumherum?

Schauen wir doch zuerst einmal auf die klassische Wasserfall Methodik. Um eine verlässliche Planung zu machen sind die Abhängigkeiten bekannt und einschätzbar. In der Praxis bedeutet dieses Kenntnis über die Infrastruktur (die Systeme um die es im Rahmen des Projektes geht), eine klare und präzise Risikoeinstufung in der es keine Extremitäten gibt. Das Risikomanagement darf dabei nicht nur Prozess Befriedigung sein, es muss wirklich gelebt werden und ist ein Instrument für die Einstufung wo Probleme entstehen können. Hohe Risiken können ein Indikator für den Einsatz von agilem Projektmanagement zur Minimierung diese Risiken sein. In Form von gezielten Aktivitäten kann ein agiler Ansatz genutzt werden um diese Risiken aus der Welt zu schaffen.

Der Scope von T&T Projekten ist vielfach ein Move von Assets aus einer Quelle in eine Zielumgebung. Kritische Faktoren sind die Menge der Systeme und die technische Transformation um den Betrieb in der Zielumgebung garantieren zu können. Würde man versuchen einen Plan zu erstellen der so verlässlich ist, dass er in entsprechender Zeit und Qualität abgearbeitet werden kann, müßte es sich um eine sehr einfache und klar strukturierte Quell- und Ziel Umgebung handeln, welche sich mit großer Wahrscheinlichkeit sehr ähnlich ist. Das ist in der Praxis nicht der Fall. Vielmehr ist es wahrscheinlich, dass die Quell Umgebung eine über die Jahre heterogen gewachsene Umgebung ist, welche eine Artenvielfalt aus IT-Technologie der vergangenen 10 – 15 Jahre darstellt. Dieses in eine moderne Zielumgebung nach Standards der heutigen Zeit zu transformieren ist keine triviale Angelegenheit. Das Gegenteil ist der Fall, es ist hochgradig komplex. Wenn zu den technischen Details auch noch organisatorisch unterschiedliche Zuständigkeiten wie unterschiedliche Provider oder Kunden Abteilungen hinzukommen wird es richtig spannend. Für die Praxis bedeutet dieses, von Beginn an müssen Sie zu jedem Asset die richtigen Informationen was die Technik und die organisatorische Eingliederung betrifft vorliegen haben.

Auf Basis der Wasserfall Methode kann jetzt für einen solchen move und Transformation ein Phasenmodell entwickelt werden. Beispielsweise könnte es sich um eine Vorbereitung, Umzug, Nachbearbeitung handeln. Die scope Liste, also die Assets um die es sich handelt sind in allen drei Phasen identisch. Das ist ein wichtiger Faktor, die Datenbasis muss von Anfang bis zum Ende identisch sein und die Referenz darf sich nicht ändern. Ein Change Management Prozess auf diese „Scope Liste“ muß im Projekt etabliert werden.

Diese Liste ist unter anderem auch die Schnittstelle für das agile Projektmanagement, denn diese Liste stellt das Product Backlog da. Im Rahmen der Wasserfall Methodik sind jetzt für jede Phase die offensichtlichen und bekannten Themen zu planen damit das agile Projektmanagement im Rahmen von Sprints das Product Backlog abarbeiten kann. Die Wasserfallen Methodik muss so detailliert planen, dass ein jeweiliger Sprint nur noch auf Probleme stößt die es mit dem interdisziplinären Team selbst lösen kann.

Hier ist jetzt auch zu erkennen warum das Riskmanagement und die sorgsame Abarbeitung der Risiken so wichtig ist. Treten hier Risiken ein und werden zum Issue, steht schlimmstenfalls das gesamte Projekt.

Innerhalb einer Phase können Test sprints dazu dienen dieses zu überprüfen. Diese Test Sprint haben aber auch noch eine weitere Aufgabe. Neben dem prüfen der Machbarkeit, also einem „proof of concept“, zeigen sie die Performance eines Sprints auf. Diese Performance kann dann genutzt werden um so zu skalieren, das es in die Planung des Phasenmodells herein passt. In der Praxis würden mehrere Sprints parallel laufen und würden ihr Sprint Backlog aus dem zentralen Product Backlog entnehmen. Die Sprint Dauer ist nicht nur von technischen Details abhängig. Auch organisatorische und prozessuale Begebenheiten spielen hier für eine Rolle. Beispielsweise changes die im Rahmen von Servicemanagement erstellt werden müssen. Hierbei sind oftmals Vorlaufzeiten einzuhalten und auch Personalplanungen und Genehmigungen können eine Rolle spielen. Die Durchführung als Sprint hat an dieser Stelle den Vorteil Pakete auf eine Laufzeit zu schnüren die eine hohe Wahrscheinlichkeit der Umsetzung haben und gleichzeitig Erkenntnisse für weitere sprints und Planungen für die Umsetzung resultieren.

Warum sollten Pakete eine hohe Wahrscheinlichkeit haben umgesetzt werden zu können? Im agilen Projektmanagement commitet sich nicht nur der PM zu dem Scope und zu den Deliverables. Im agilen Ansatz ist das eine wichtige Teamaufgabe. Basierend auf der „Schwarmintelligenz“ des Teams gibt es das Artifakt des Sprint Planning. Dort müssen alle Team Mitglieder zum Ziel ein commitment abgeben und sollten dieses auch nur tun, wenn sie wirklich daran glauben. Hier geht es um offene Kommunikation und nicht um Hierarchie.

Nach jedem abgeschlossenen Sprint ist eine Retrospektive durchzuführen bei der der Kunde eingebunden ist. Probleme und Erkenntnisse werden auf diese Art transparent gemacht und können die weitere Planung und Ablauf optimieren. Die Abnahme eines Sprints bzw das Ergebnis eines Sprints ist im Modell des agilen Projektmanagement obligatorisch durch den Kunden. Dieser Punkt ist extrem wichtig, wenn es um vertragliche Deliverables geht. Nicht selten hängt davon die Zahlung an den Provider ab.

Fazit: Agiles und klassisches Projektmanagement passen gut zusammen. Es ist komplizierter als eine Methode allein aber agiles PM ist ein Werkzeug, welches generell nicht mehr wegzudenken ist. Der hybride Ansatz ist gut und erfordert im Projektmanagement und auch im operativen Management ein wenig Basiswissen- Grundverständnis. Ist dieses der Fall profitieren alle davon.