Agiles Projektmanagement – Ein Antagonismus?

Wohin ich auch sehe: ich bekomme den Eindruck, dass nahezu alle Projekte agil durchgeführt werden. Insbesondere große Organisationen wenden nun auch agile Vorgehensweisen (i.d.R. Scrum) an.

Dadurch entstehen zahlreiche Diskussionen, wie man das klassische Projektmanagement mit agilen Vorgehensweisen verbinden kann oder ob dies überhaupt möglich ist. Große Organisationen mit einem meist höheren Bedarf an Formalismen müssen nach wie vor gewisse Unternehmensstandards erfüllen, auch wenn diese agile Methoden für Projekte oder Produktentwicklungen einsetzen. Die Erfüllung dieser Anforderungen an die IT-Governance wurden „früher“ durch die sogenannten IT-Projektleiter bzw. IT-Projektmanager sichergestellt. Wo ist nun der Platz dieser Mitarbeiter in der agilen Welt und wie werden diese Anforderungen erfüllt? Wie kann ein agiles Projektmanagement aussehen und kann es so etwas überhaupt geben?

Zu Beginn eine kurze Begriffsklärung: Was bedeutet eigentlich das Wort „Manager“?

„Aus www.vocabulary.com:
The probable origin of the word manager comes from the Latin manus, meaning „hand.“ A good manager provides the necessary „hand,“ guiding others.
The Italian maneggiare means „to control,“ and was especially used with reference to training horses, a job for which certain managers you’ve worked for might be better suited.“

Nun kann jeder selbst entscheiden, ob der lateinische Ursprung oder der aus dem Italienischen passender und für alle Beteiligten angenehmer ist. Ich wähle einmal den Ersteren …

Das „klassische“ Projektmanagement

Die größten Organisationen für Projektmanagement (IPMA/GPM: International Project Management Association/Deutsche Gesellschaft für Projektmanagement und PMI: Project Management Institute) sehen für einen Projektmanager beispielsweise folgende Aufgabengebiete vor:

Auch wenn diese Aufstellung für kleinere Vorhaben auf den ersten Blick sehr umfangreich erscheint; die darin enthaltenen Aufgaben müssen bei jeder Art von Projekten in einer gewissen (und zwar in einer angemessenen) Art und Weise erledigt werden. Vorgehensmodelle für die Projektdurchführung wie das V-Modell XT oder der Rational Unified Process adressieren diese Anforderungen. Dazu passend gibt es beispielsweise beim V-Modell XT eine Softwareunterstützung, die eine komplette Projektstruktur inklusive Meilensteinplan und zu erstellenden Artefakten auf Knopfdruck erzeugt. Sehr leicht bedienbar und übersichtlich; schon hat man einen kompletten Meilensteinplan und diesen sogar in MSProject importierbar … !

Die Gefahr liegt meines Erachtens nun darin, dass kein Hinterfragen auf die Sinnhaftigkeit der Aufgaben im konkreten Projektzusammenhang erfolgt. Es werden dann Dinge erledigt und Dokumente oder andere Artefakte erzeugt, die in diesem Umfang und in dem Projektkontext gar nicht benötigt werden. Schnell wird der Projektmanager dabei zu einem Verwalter von Checklisten und befolgt gebetsmühlenartig die vorab festgelegten Pläne.

Dazu ein Erfahrungsbricht aus einem Festpreisprojekt:

„Unsere Firma hatte ein Projekt als Werkvertrag unter Verwendung des V-Modells XT durchgeführt. Der Go-Live-Termin, und damit die größte Abschlagszahlung, stand kurz bevor. Alle relevanten Tests und Vorbereitungen waren (mehr oder weniger gut) abgeschlossen. Zumindest so gut, dass wir nächste Woche den Rollout starten konnten.

Doch dann kam der Tag, an dem der Projektmanager des Kunden auf die Idee kam, einmal in das Projektmodell des V-Modells hinein zu schauen um festzustellen, dass eine Vielzahl von Dokumenten von unseren Leuten gar nicht erstellt wurden. Diese wurden nach Meinung der Projektteams auch gar nicht benötigt. Geschrieben wurden diese dann doch noch, und zwar in zahlreichen Nachtschichten, denn das Modell sah dies ja nun mal vor. Reingesehen hat in die Dokumente später niemand mehr.“

Abgesehen davon, dass es nicht besonders sinnvoll ist, ohne Reflexion über die aktuellen Gegebenheiten auf die strikte Einhaltung von Verträgen zu pochen (s.a. 3. Wertepaar des agilen Manifests) neigen Projektmanager (und natürlich auch andere Beteiligte) dann dazu, komplexe Problemstellungen immer mit derselben Herangehensweise zu lösen, nämlich so wie es das Modell will. Dies kann nicht funktionieren, denn bei komplexen Problemen müssen emergente Strategien zu deren Lösung angewandt werden. Dies wird beispielsweise von Dave Snowden mit seinem Cynefin-Framework oder auch Ralph Stacey in seinem Modell erläutert.

Und Agile?

Bei verhältnismäßig einfachen und kleinen Projekten mit entsprechend kleinen und lokalen „On-Site“-Teams sind agile Methoden noch einfach anwendbar. Die Wege sind kurz, die Anzahl der Kommunikationskanäle gering und ein regelmäßiger Austausch der Projektteilnehmer ist leicht möglich.

Doch nun sollen auch Projekte mit verteilten Teams und Hunderten von Projektteilnehmern agil durchgeführt werden. Damit stößt so manche Projektorganisation an ihre Grenzen, denn die strikte Anwendung des Scrum-Guide (als Beispiel des bekanntesten agilen Vorgehensmodells) reicht dann u.U. nicht mehr aus. Hier gibt es erst einmal nur die drei Rollen Product Owner, Scrum Master und Entwicklungsteam.

Siehe dazu auch ein Interview mit Alistair Cockburn vom Juli 2014: „Interview mit Dr. Cockburn“

Fragt man einen Scrum-Evangelisten darüber, wer denn künftig die Projektmanagementaufgaben wahrnehmen soll, zaubert man entweder Fragezeichen in das Gesicht des Gegenüber oder erhält so eine oder ähnliche Antwort:

„Die operative Projektplanung liegt bei dem Entwicklungsteam während die strategische Projektplanung durch den Product Owner (PO) durchgeführt wird.“

Dabei stellt sich dann die Frage, welche der über ein Dutzend oben genannter Aufgabenfelder der operativen, und welche der strategischen Planung zuzuordnen sind, und wer überhaupt die Ausbildung und Erfahrung hat, diese Aufgaben zu erfüllen. Und natürlich wo genau im Scrum Guide eigentlich steht, dass dies gemacht werden muss … Das Entwicklungsteam sollte doch eigentlich Code produzieren; der PO hat sich um die Produktvision und den ROI der beauftragten Softwareartefakte zu kümmern … keine Zeit für die anderen Dinge …

Das Problem hierbei: Wichtige Tätigkeiten werden weggelassen und führen insbesondere bei großen Vorhaben zu vielfältigen Problemen. Agile Vorgehensweisen kommen dadurch in Verruf; wer hat nicht schon einmal das Vorurteil gehört: „Agile Projekte? Ach ja, das sind die Projekte in denen nichts mehr dokumentiert wird … .“

Doch auch bei der Anwendung von agilen Vorgehensweisen müssen alle Beteiligten genauso die Sinnhaftigkeit bzgl. der Abbildung von Projektmanagementaufgaben hinterfragen wie bei den bisherigen Methoden.

Dabei sieht Scrum diesen Inspect and Adapt-Zyklus sogar zwingend vor! Leider habe ich aber die Erfahrung gemacht, dass dieser in den Scrum-Teams „stecken bleibt“ und nicht auf den weiteren Ebenen der Organisation angewendet wird. Eine regelmäßige Retrospektive von Abteilungsleitern bis C-Level (je nach Projektgröße) könnte da sicherlich wahre Wunder bewirken.

Wieder mehr Formalismus?

Viele Organisationen haben keine guten Erfahrungen mit der Anwendung agiler Vorgehensweisen gemacht und sind auf der Suche nach Modellen, die den Bedarf an mehr Formalismus unter Beibehaltung einer gewissen „Agilität“ bedient.
Und so kommen wir zu eher strikten Modellen wie beispielsweise dem Scaled Agile Framework (SAFe) . Und auch hier sehe ich genauso wie bei dem zuvor gezeigten V-Modell XT die Gefahr, dass ohne Nachzudenken Tätigkeiten durchgeführt und Artefakte erzeugt werden, nur weil es im Modell so gefordert wird.

Und nun?

Während das strikte unreflektierte Befolgen von vorab festgelegten Anweisungen in der Vergangenheit oft nicht von Erfolg gekrönt war, ist es ebenso gefährlich sämtliche Ideen der letzten Jahrzehnte zum (IT-)Projektmanagement mit der Begründung über Bord zu werfen, dass man nun agil sei. Besonders gefährlich wird es meines Erachtens, wenn Agilisten oder agile Coaches ohne Erfahrung in der Leitung von IT-Projekten versuchen, große Projekte agil durchzuführen.

Denn ohne langjährige Praxiserfahrung kann, beispielsweise in einem Scrum-Projekt, nichts anderes getan werden, als die Vorgaben des Scrum Guide eins zu eins umzusetzen („Ein Standup darf genau 15 Minuten dauern!“ :-)). Und da sind wir dann wieder bei derselben Gebetsmühle wie der Projektleiter zuvor mit seinen durch das V-Modell XT vorgegebenen Tätigkeiten.

Agiles Projektmanagement ist kein Solospiel mehr

Die Aufgaben des Projektmanagements fallen nicht einfach weg, nur weil man plötzlich agil ist. Stattdessen ist es wichtig, dass die Dinge zur richtigen Zeit an die richtigen Personen adressiert werden. Dazu braucht es vor allem viel Erfahrung und gute Teammitglieder die bereit sind, ihren Beitrag zu einem Projekt nicht nur auf ein vorab genau beschriebenes Aufgabengebiet zu beschränken, sondern sich zu allen Problemstellungen die auf dem Weg auftreten, einzubringen und mitzumachen.

Jeder Projektbeteiligte kann und muss künftig seinen Beitrag dazu leisten, sei es nun für eine Stakeholderanalyse, einer Risikobetrachtung und so weiter. Wer diese Themen zur Sprache bringt ist dabei egal, es muss nur sichergestellt sein, dass es passiert!

Ich bin der Meinung, dass ein ehemaliger Projektleiter/-manager aufgrund seiner Ausbildung und Erfahrung dafür gut geeignet ist. Wie diese Rolle dabei künftig genannt wird, sei dann der Phantasie des Unternehmens überlassen. Denn gerade in großen Organisationen reicht es nicht mehr aus, alle Aufgaben beim Product Owner abzuladen. Voraussetzung ist dabei natürlich, dass der ehemalige Projektleiter/-manager die Werte und Prinzipien agiler Vorgehensweisen verinnerlicht hat.

Dabei fällt mir auch gleich der erste Satz des agilen Manifests ein:

„We are uncovering better ways of developing
software by doing it and helping others do it.“

Dies passt dann auch wieder gut zum (lateinischen) Ursprung des Wortes „Manager“!

Wie ist Eure Erfahrung mit dem „agilen Projektmanagement“ insbesondere bei großen Projekten?

Falls jemand auf der Manage Agile ist: Ich freue mich auf einen Besuch bei meinem Talk zu dem Thema!