Viele halten agile Prozesse als den einzig richtigen Weg, wie man heute Projekte oder Produkte entwickelt. Dabei gab es in der Vergangenheit auch viele erfolgreiche Projekte, die mit traditionellen Projektmanagementmethoden abgewickelt wurden. Zugegebenermaßen ist die Erfolgsquote in agilen Projekten höher. Trotzdem lohnt sich ein Blick über den Tellerrand, denn auch in agilen Projekten läuft nicht immer alles rund. Aus meiner Sicht gibt es viele Dinge, die man vom traditionellen Projektmanagement lernen kann, die auch im agilen Kontext nützlich sind.

23. Agile Brakfast mit Marc Löffler

23. Agile Brakfast mit Marc Löffler

Zunächst einmal möchte ich aber auf die Dinge eingehen, die aus meiner Sicht heutzutage keinen Sinn mehr machen. Da wären zum einem die unsäglichen PSP (Projektstrukturpläne), u.a. in Form von GANTT Charts, die bereits am Tag 1 nach der Erstellung schon wieder obsolet sind. Niemand kann in die Zukunft sehen und bis heute haben Meteorologen Probleme, das Wetter für den nächsten Tag mit absoluter Sicherheit vorherzusagen. Es macht also absolut keinen Sinn, einen detaillierten Plan zu machen, wenn man ihn mit großer Wahrscheinlichkeit so nicht durchführen kann. Außerdem führt ein solcher Plan oft dazu, dass man im Projekt mehr macht, als vielleicht notwendig gewesen wäre, anstatt die Summe nicht getaner Arbeit zu maximieren.

In keinem Bericht wird so viel gelogen wie in Statusberichten. Vor ein paar Jahren habe ich einen Blogpost dazu geschrieben, der das Phänomen des „Wassermelonenreportings“ beschreibt: Das Team weiß schon lange, dass der Termin nicht mehr zu halten ist und gibt die Info (Status: rot) auch an seinen technischen Projektleiter weiter. Dieser will sich aber keine Blöße geben und setzt den Status lediglich auf gelb. Der Projektleiter sieht das und gibt den Status in grün an das Management weiter, weil er keine Lust hat, sich in irgendwelchen Besprechungen zu rechtfertigen. So bekommt das Management den Eindruck, dass alles in bester Ordnung ist, obwohl schon lange klar ist, dass das Projekt nicht mehr zu schaffen ist. Auf diese Weise entsteht also eine schöne Wassermelone: Innen knallrot, aber nach außen sieht alles schön grün aus. Dies lässt sich vor allem in Unternehmen beobachten, in denen es kaum Transparenz gibt.

Jetzt wird es aber Zeit, dass wir uns den positiven Dingen zuwenden. Im traditionellen Projektmanagement sind nämlich ein paar Perlen verborgen, die auch in jedem agilen Projekt Sinn machen.

Anfangen möchte ich mit der Teamzusammensetzung. Jeder gute Projektleiter weiß, dass das richtige Projektteam eines der wichtigsten Faktoren für ein erfolgreiches Projekt ist. Es macht keinen Sinn, einfach alle gerade verfügbaren Leute in ein neues Projekt zu stecken. Die Zusammensetzung ist elementar wichtig. Die richtige Balance zwischen Kompetenz und Diversität zu finden, ist hier die große Kunst. Wenn ich z.B. in einem agilen Team einen eher ruhigen, introvertierten Product Owner habe, sollte ich ihm einen aktiveren, extrovertierten UX Designer und Scrum Master zur Seite stellen. Wenn der UX Designer auch zu der ruhigeren Sorte gehört, besteht sonst die Gefahr, dass die Kommunikation im Team zum Erliegen kommt. Aus meiner Sicht wird auf die richtige Teamzusammensetzung oft viel zu wenig Wert gelegt. Wenn man das richtig angeht, legt man bereits den Grundstein für ein erfolgreiches Projekt.

Genauso macht es Sinn, zu verstehen, welche Stadien ein Team in der Teambildungsphase durchläuft, damit man die einzelnen Phasen entsprechend beeinflussen kann. Hier hilft u.a. die Teamuhr nach Tuckman, welche die einzelnen Phasen (Forming, Storming, Norming, Performing und Adjourning) und die Rolle des Projektleiters (in agilen Projekten die des Scrum Master) in diesen Phasen beschreibt. Auch dies ist wertvolles Wissen aus dem traditionellen Projektmanagement.

Es ist immer wieder verwunderlich, wie viele Projekte auf ein Kick-Off am Anfang eines Projekts verzichten oder versuchen, es innerhalb einer Stunde „durchzuziehen“. Die in einen solchen Workshop investierte Zeit bekommt man nachher doppelt und dreifach zurück. Das Kick-Off Meeting hat sich als idealer Ort herausgestellt, um ein gemeinsames Verständnis für die Projektziele zu schaffen und alle Teilnehmer auf den gleichen Stand zu bringen. Jeder Mitarbeiter sollte am Ende des Kick-Offs wissen, warum er in diesem Projekt ist und was man am Ende erreichen will. Auch darf man den Nutzen des Kick-Offs für das Teambuilding nicht unterschätzen. Auch wenn ein solcher Workshop in Scrum nicht vorgesehen ist, sollte er in keinem agilen Projekt fehlen.

Kennen Sie die Ziele ihres derzeitigen Projekts? Nein? Da sind sie nicht allein. Ein Großteil der Projekte, denen ich begegnet bin, hatten keine oder nur unzureichenden Ziele definiert. Wie aber soll ein Mitarbeiter autonom Entscheidungen treffen können, wenn er nicht weiß, welche Ziele erreicht werden sollen. Die Ziele eines Projekts werden am besten im Kick-Off erarbeitet. So stellt man zum einen sicher, dass alle Projektmitarbeiter abgeholt werden und zum anderen, dass sie sich auch mit den Zielen identifizieren können. Besonders wichtig ist hier auch, dass die Nicht-Ziele definiert werden, damit jeder weiß, was definitiv nicht Teil des Projekts ist. Ein weiterer Vorteil von sauber definierten Zielen ist, dass der Product Owner besser gegenüber Stakeholdern argumentieren und somit verhindern kann, dass Anforderungen ins Projekt kommen, die nicht mit den Zielen übereinstimmen. Aus meiner Sicht sollten gemeinsam definierte und messbare Ziele in keinem agilen Projekt fehlen.

Ein weiteres Thema aus dem traditionellen Projektmanagement, dass meiner Ansicht nach in agilen Projekten oft nur stiefmütterlich behandelt wird, ist das Stakeholdermanagement. Eigentlich hat dieses Thema in Scrum eine recht hohe Priorität, da man versucht Kunden und Stakeholder eng in das Projekt einzubinden. Nur gelingt das vielen Teams nicht so gut, weil entweder der direkte Kontakt zu Stakeholdern fehlt oder diese falsch eingebunden werden. Beispielsweise ist es nicht das primäre Ziel des Sprint Reviews zu zeigen, an was man im letzten Sprint gearbeitet hat.  Das primäre Ziel ist, Feedback von den Stakeholdern zu bekommen, das dann wiederum in das Projekt mit einfließt. Außerdem macht es Sinn, den Einfluss und die Konfliktwahrscheinlichkeit der einzelnen Stakeholder zu kennen, weil es durchaus Stakeholder gibt, die man intensiver in das Projekt einbinden muss als andere, damit sie das Projekt am Ende nicht torpedieren.

Jedes Projekt ist diversen Risiken ausgesetzt, die man nicht aus dem Augen verlieren sollte. Auch hier hat Scrum schon von Hause aus einige Sicherheitsmechanismen eingebaut, wie z.B. kurze Iterationen. Trotzdem macht es Sinn auf der Basis einer Umfeldanalyse eine ausführliche Risikoanalyse des Projekts zu machen und proaktive, wie auch reaktive Maßnahmen zu definieren. Gute Projekte managen ihre Risiken – und nicht anders herum. Hier macht es Sinn, die Methoden aus dem agilen und traditionellen Projektmanagement miteinander zu verbinden.

Die meisten Planungstools aus dem traditionellen Projektmanagement haben in der agilen Softwareentwicklung ausgedient. Ein Tool, das ich aber weiterhin als wertvoll erachte, ist der Phasenplan. Er definiert auf sehr hohem Level, wie die einzelnen Dinge in einem Projekt zusammenfließen. Besondern in Projekten mit mehreren Teams kann ein übergeordneter Plan sinnvoll sein, um sich teamübergreifend leichter abstimmen zu können. Hier können auch Meilensteine definiert werden, an denen z.B. wichtige Integrationsarbeiten zwischen einzelnen Gewerken stattfinden. Denn nicht immer hat man es mit reinen Softwareentwicklungsprojekten zu tun.

Wie so oft lohnt sich also der Blick über den Tellerrand. Nicht alles, was aus dem traditionellen Projektmanagement kommt, sollte man von vorneherein verteufeln. Im Endeffekt können sich traditionelles und agiles Projektmanagement wunderbar ergänzen. Am Ende ist es immer der jeweilige Kontext an den man seine Vorgehensweise anpassen muss.