Thought Leadership
Agiles Projektmanagement ist auf dem Vormarsch. Methoden wie Scrum oder Kanban, die in der Softwareentwicklung schon länger zum Standard gehören, setzen sich auch in anderen Bereichen mehr und mehr durch.
Für viele Manager scheinen sie für ein zeitgemäßes, progressives Arbeiten zu stehen. Ein Trend, auf den sie gerne aufspringen möchten. Aber ist das wirklich so? Hat klassisches Projektmanagement ausgedient, weil es den Anforderungen der modernen Arbeitswelt nicht mehr entspricht?
Während die klassischen Projektmanagement-Methoden den Fokus auf Strukturen, langfristige Planung und detaillierte Spezifikationen legen, geht es bei agilem Projektmanagement vor allem um ein iteratives Vorgehen mit kurzen Feedback-Schleifen und die Einhaltung fester Werte und Prinzipien. Selbstorganisation, Selbstverantwortung und Entscheidungskompetenz der operativen Teams sind wesentliche Grundpfeiler dieser Vorgehensweise.
Das durchgängig iterative Vorgehen im agilen Management ermöglicht einen flexiblen Umgang mit sich ändernden Zielanforderungen. Daher ist es gerade bei Entwicklungsprojekten mit hohem Termindruck geeignet, bei dem die Anforderungen an das zu entwickelnde Produkt zu Beginn des Projekts noch unklar sind. Diesen Vorteil möchten viele Manager zunehmend auch in anderen Projekten mit dynamischen Rahmenbedingungen nutzen. Doch die Erfahrung zeigt, dass sich nicht jedes Projekt für einen rein agilen Ansatz eignet und nicht jeder Start in die agile Kultur auf Anhieb glückt.
Anhand des folgenden Beispiels eines Rechenzentrums-Umzugs in die Cloud möchte ich darstellen, wo typischerweise Schwierigkeiten entstehen können. Die Zielsetzung des Projekts: Rund 1000 Server mit den darauf laufenden Applikationen, welche von verschiedenen Fachbereichen verwendet werden, zu einem Dienstleister in die Cloud umzuziehen, ohne dabei den laufenden Betrieb zu stören.
Nicht klassisch, aber auch nicht wirklich agil
Bereits ein gewöhnlicher Rechenzentrums-Umzug ist ein umfangreiches Vorhaben. Noch komplizierter wird es, wenn es um einen Umzug in eine neue technische Welt – in diesem Fall in die Cloud – geht. Zusätzlich ist seitens der Fachbereiche zu berücksichtigen, dass es nutzungsbedingte Ausschlusszeiten für einen Umzug gibt und dass die für die Vorbereitungsarbeiten erforderlichen Mitarbeiter vorrangig in anderen Projekten eingebunden sind. Für den verantwortlichen Manager ist von Anfang an klar: Wir managen dieses Projekt agil, um auf kurzfristige Änderungen besser reagieren zu können. Unser Team erhält den Auftrag, sich bei der Durchführung des Projekts eng an Scrum zu orientieren und geeignete Prozesse aus diesem Framework einzuführen.
Bild: Ablauf im hybriden Projektmanagement (Quelle: House of PM).
Für die iterative Vorgehensweise legen wir zunächst die Dauer der Iterationszyklen (sogenannte Sprints) fest, führen ein Sprint Planning, ein Daily Stand Up, eine Retrospektive und ein Refinement Meeting ein. Ganz bewusst entscheiden wir uns jedoch von Anfang an auch für klare Abweichungen zum agilen Prinzip. So wird das Projekt von einem dedizierten Führungsteam gesteuert. Dieses besteht aus einem Projektleiter, der die Gesamtverantwortung innehat, einem Technical Lead und der „Zeremonienmeisterin“, die für die Einhaltung der Methodik verantwortlich ist. Da es sich hier nicht um eine Produktentwicklung handelt, wird die Rolle des Product Owners nicht vergeben.
Bei Start unseres Projekts sind viele Server bereits virtualisiert, einige müssen jedoch noch komplett umgestellt werden. Auch seitens der Applikationen ist eine Reihe von Vorarbeiten zu erledigen. Bevor die eigentlichen Server-Umzüge starten können, muss außerdem die Infrastruktur bei dem Dienstleister aufgebaut werden. Im Laufe der ersten Sprints zeigt sich, dass unser Team wiederholt die gesetzten Sprintziele nicht erreicht. Die Hauptursachen: Zwischen den einzelnen Aufgaben im Sprint-Backlog bestehen zu viele Abhängigkeiten und es gibt Einflüsse von außen, die nicht ohne weiteres abgestellt werden können. Hinzu kommt, dass das sehr heterogene Team zuvor noch nie agil gearbeitet hat und uns Erfahrungen bei der Einschätzung des umsetzbaren Arbeitsumfangs innerhalb eines Sprints fehlen. Auch ist noch nicht bei allen die Bereitschaft und die Fähigkeit zur Selbstorganisation gegeben und verinnerlicht – eine Grundvoraussetzung für agiles Arbeiten. Obendrein sind die Teammitglieder nicht zu 100 Prozent auf dem Projekt eingesetzt, sondern haben zusätzlich noch ihr Tagesgeschäft zu erledigen. Das agile Modell sieht vor, dass keine weiteren Aufgaben von außen in das Projekt einfließen.
Nach einigen Sprints stellt sich Unzufriedenheit im Team, bei den Stakeholdern und den Führungskräften ein und das Projekt droht aus dem Ruder zu laufen. War die agile Methodik vielleicht doch nicht die richtige Wahl? Obwohl das Management unbedingt an ihr festhalten will, erscheint auch ihm eine klassische Herangehensweise teilweise besser zu den gegebenen Umständen zu passen. Aufgrund der Teamstruktur und der verschiedenen Abhängigkeiten soll bei einigen Abläufen auf eine stärkere Führung und langfristigere Planung zurückgegriffen werden, um die Ziele im dafür vorgesehenen Zeitraum zu erreichen.
Von beidem das Beste
Mithilfe der Erkenntnisse aus den Retrospektiven findet unser Team zu einem für uns passenden hybriden Vorgehensmodell. Unsere Sprints bestehen im Prinzip wiederholt aus drei Aufgabenblöcken: Vorbereitung – Umzug – Test. Bei genauer Analyse stellen wir fest, dass die eigentlichen Umzüge gut funktionieren und weiterhin agil gemanaged werden können. Ebenso sollen die Arbeiten zum Aufbau der Infrastruktur und Vorbereitungen des Dienstleisters (z.B. Speicherbeschaffung) für die Umzüge trotz der Abhängigkeiten zwischen den Arbeitspaketen weiterhin agil laufen. So hilft uns beispielsweise das Daily Stand Up, kurzfristig Probleme zu identifizieren, die zu Fallstricken werden können. Die Retrospektive gibt allen Teambeteiligten die Möglichkeit, schnell und regelmäßig Kritik zu äußern und so das Projekt aktiv mitzugestalten – ohne dieses Instrument und den damit verbundenen Input des Teams, wäre eine kontinuierliche Prozessoptimierung in der Geschwindigkeit nicht möglich.
Instrumente aus dem agilen Projektmanagement
Sprint
Ein Sprint ist ein Arbeitsabschnitt mit vorgegebener fixer Zeitdauer, in dem ein vom Team festgelegter Umfang der Arbeiten aus dem Backlog umgesetzt und ein nutzbares Ergebnis geliefert wird. Sprints folgen unmittelbar aufeinander.
Backlog
Das Backlog listet die zu erledigenden Arbeiten (in unserem Fall Applikationen und Vorarbeiten) auf.
Sprint Planning
Das Sprint Planning Meeting findet zu Beginn eines Sprints statt. Hier werden die User Stories – oder in unserem Fall Applikationen und grob geplante Vorarbeiten – aus dem Backlog genommen und detailliert geplant.
Retrospektive
In der Retrospektive, die am Ende des Sprints stattfindet, schaut das Team zurück auf den Entwicklungsprozess und die Zusammenarbeit im Team und untersucht diese auf Verbesserungspotenziale. Dadurch wird eine kontinuierliche Verbesserung ermöglicht und das Aufstauen von Frust im Team vermieden.
Sprint Review
Im Review-Meeting am Ende des Sprints wird im Team und mit den Stakeholdern auf die Ergebnisse des Sprints geschaut und diese hinsichtlich des im Planning gesetzten Sprint-Ziels bewertet.
Refinement
Im Refinement werden alle im Backlog befindlichen Einträge in die Release Planung aufgenommen. Sie werden bereits grob geplant, damit sichtbar wird, welche Vorbereitungen u.U. noch getroffen werden müssen, damit z.B. eine Applikation zum geplanten Zeitpunkt umziehen kann.
Grooming
Die Begriffe Grooming und Refinement werden häufig synonym benutzt. Der Begriff Refinement hat im Laufe der Zeit den Begriff Grooming abgelöst.
Die vorbereitenden Maßnahmen und Tests in den Fachbereichen hingegen benötigen eine engere Führung der Mitwirkenden und werden ab sofort klassisch organisiert. Mittels einer groben Projektplanung können wir die Abhängigkeiten transparent machen und die Aufgaben im Backlog optimal strukturieren. Ergänzend führen wir in regelmäßigem Turnus eine Sprint-Vorausplanung und ein Grooming ein. In der Sprint-Vorausplanung legen wir grob den Umfang der kommenden vier Sprints fest. Das Grooming ist in unserem Fall ein Meeting, das kurz vor dem Sprint-Planning stattfindet und den Folgesprint des kommenden Sprints detaillierter plant. Es ist also nach dem Refinement eine weitere Konkretisierung der Planung vor dem eigentlichen Sprint-Planning. Damit soll erreicht werden, dass eine Applikation zum geplanten Zeitpunkt tatsächlich umzugsbereit ist und nicht z.B. aufgrund von fehlendem Speicher auf der Zielplattform zurück ins Backlog geschoben werden muss. Das Grooming und die Sprint-Vorplanung sind für uns hilfreich, um eine langfristige Planung zu gewährleisten, Hindernisse früh zu erkennen und Vorbereitungen rechtzeitig zu treffen.
Die Aufteilung der jeweiligen Methoden im Führungsteam gestaltet sich gut: Die Verantwortung für die agilen Themen liegen weiterhin bei der „Zeremonienmeisterin“. Der Projektleiter ist für den klassisch gemanagten Bereich zuständig. Er stimmt mit den Fachbereichen alle Aufgaben ab, um die Applikationen in den Status „Bereit zum Umzug“ zu überführen (z.B. notwendige Updates und Virtualisierungen) und erstellt dazu einen Zeitplan. Diese Planung wird in die Sprint-Vorausplanung aufgenommen und so die Verbindung zur agilen Welt geschaffen. Als Schnittstelle zwischen beiden Welten übernimmt die Zeremonienmeisterin für die Unterstützung bei der Planung und Organisation der Umzüge zusätzlich die Rolle des „Umzugskoordinators“. Dazu steuert sie innerhalb der Sprints anhand der erstellten Checkliste die notwendigen Arbeiten für den eigentlichen Umzug (Vorbereitung, Durchführung und Nachbereitung). Dank der neuen hybriden Arbeitsweise gelingt es dem Team, die einzelnen Sprints besser zu planen und die gesetzten Sprint-Ziele zu erreichen.
Was wir daraus lernen können
Im dargestellten Fall ist keinem der Beteiligten vorab klar gewesen, wie viel Vorarbeit für das Projekt nötig sein würde und welche Abhängigkeiten zwischen den einzelnen Aufgaben bestehen. Ein Rechenzentrumsumzug dieser Größenordnung ist für alle Neuland. Es gibt weder ausreichend Erfahrung mit einer solchen Aufgabe, noch mit agilen Methoden – ein entscheidender Punkt für die Planung, der oft nicht ausreichend berücksichtigt wird. Es dauert, bis sich ein Team eingespielt und auf ein Vorgehen eingestellt hat. Scheitern gehört zu diesem Prozess naturgemäß dazu. Unsere Empfehlung: Genug Zeit und Spielraum einzuplanen und dabei die Größenordnung der Unternehmung nicht zu unterschätzen, trägt entscheidend zum Projekterfolg bei. Auch ein realistischer Blick auf die eigene Mannschaft und Unternehmenskultur ist unerlässlich: Passt die gewählte Projektmanagement-Methode überhaupt zum Team? Stimmen die Rahmenbedingungen? Und wenn nicht? Dann ist es wichtig, flexibel auf die gegebenen Umstände zu reagieren, sein Vorgehen kritisch zu hinterfragen und nicht starr an einer Methode festzuhalten. Nur so lässt sich prüfen, ob man sich noch auf dem richtigen Weg befindet oder umdenken muss. Umdenken heißt auch: Alternativen in Betracht ziehen. Wenn ein agiles Konzept nicht die gewünschten Resultate bringt, ist ein individuell zusammengestelltes, hybrides Modell oft die bessere Wahl. Einfach nur auf einen vermeintlichen Trend aufzuspringen, bringt niemanden weiter. Denn das hehre Ziel ist schließlich, die Aufgabe erfolgreich zu meistern.
Julia von Bomsdorff ist studierte Kulturwissenschaftlerin und seit 2008 als Projektmanagerin für das House of PM im Einsatz. Zuvor war sie in unterschiedlichen Funktionen in den Bereichen Content- Management (Print und Online), Online-Marketing und Controlling tätig. Von Bomsdorff ist zertifizierte Projektmanagementfachfrau (IPMA Level D), Project Management Professional (PMI®) sowie Professional Scrum Master (PSM I) und verfügt über das PRINCE2® Foundation- Zertifikat (APMG).
