Ich bin mir nicht sicher, was ich von dem Beitrag halten soll.

Ich sehe es als Problem, wenn aus agilen Methoden ein neuer "Best Practice" wird. "Best Practices" sind Projekt-Alchemie, die die fundamentale Einmaligkeit von Projekten ignoriert.

Tatsächlich sind agile Methoden nach Befragungen für ca. 1/3 der Projekte/Projektsituationen geeignet. Bleiben 2/3, wo sie es nicht sind.

Als Projektmanager sollte man daher zuerst prüfen, welchen Anforderungen man in einem besonderen Moment gegenüber steht, und anschließend situativ passende Methoden auswählen und einsetzen.

Noch ein Problem: Immer mehr Projekte werden heute als Kundenprojekte für zahlende Kunden durchgeführt, der Trend ist messbar. Agile Methoden ignorieren diesen Trend jedoch weitgehendst und gehen, wie leider auch der Autor des Artikels, davon aus, dass Projekte interne Aktivitäten sind. Projektgeschäft stellt jedoch andere Anforderungen an Projektmanager - auf beiden Seiten, Kunde und Lieferant - als interne Projekte.

Wer nur einen Hammer hat, um seinen Lebensunterhalt zu verdienen, muss die Welt überzeugen, dass sie genagelt ist. Wer nur über einen Schraubendreher verfügt, muss die Welt glauben machen, sie sei verschraubt.

Hi zusammen,

genau genommen haben wir hier 2 Herausforderungen:
1. wir befinden uns auf einer Website, die vom klassischen Projektmanagement her kommt.
2. Mario Neumann ist seit vielen Jahren ein klassischer Berater für Projekte.
Beide müssen nun "irgendwie" dieses agile "Zeug" berücksichtigen. Wie kann dieses "irgendwie" gelingen? Schwierig, wie man sieht. Etwa die Hälfte der Kommentatoren haben Mühe mit dem Artikel.

Im Einzelnen:
* Im Grunde hat Mario Recht. Der klassische Projektleiter muss sich neu orientieren.
* Er irrt jedoch (mit Einschränkung) über das Wie. Seiner Meinung nach hat es Platz für alle 3: Scrum-Master, Product-Owner und Projektleiter. Das ist falsch. Es benötigt den Projektleiter in der (weiteren) Zukunft nicht mehr.
* Dessen Aufgaben werden stattdessen auf den PO und den SM verteilt. Zum Beispiel wird die Tabelle korrekt, wenn man die Überschrift der 2. Spalte anstelle von "Der agile Projektleiter..." umformuliert in "Der Scrum-Master...". Denn dies sind alles Aufgaben des Scrum-Masters.
* Berücksichtigt man dies nicht, dann sind Konflikte wegen Überschneidungen zwischen den 3 Rollen vorprogrammiert.

Welche Einschränkung meinte ich oben? Auf dem Weg von der Wasserfall-Welt weg kann der PL wertvolle Beiträge liefern, um das agile Produktteam von einer Organisation abzuschirmen, die von einem Projekt noch sehr viel will: bei uns waren das Quality Gates, Quality Points, RFAs (Request for Architecture), PKAs (Projektkreditanträge), etc.
Wenn also das Team agil arbeitet, das Unternehmen aber weitestgehend in der Wasserfall-Welt verharrt, hat der PL die wichtige Aufgabe, sein Team abzuschirmen, sodass sie in Ruhe agile Produktentwicklung betreiben können. Ich selbst habe lange Jahre als PL genau dies gemacht. Wichtig ist herbei, dass er keine der vielfältigen Aufgaben des POs und des SMs übernimmt. Ob das noch interessant ist, muss sich jeder PL selbst stellen. Er ist für viel weniger verantwortlich als vorher. Auf diese Weise könnte er jedoch viel mehr Projekte als vorher betreuen und sich so breiter aufstellen. In die Tiefe dringt er so jedoch nicht mehr.

Hat das Unternehmen die Wasserfall-Welt dann endlich hinter sich gelassen, dann sollte sich der PL entscheiden, ob er lieber PO oder lieber SM machen möchte. Unser Unternehmen ist gerade mitten in der Umstellung auf eine produktorientierte Organisation. Dann gibt es nur noch Produktteams und Serviceteams mit den entsprechenden agilen Rollen.

Zu den Kommentaren von...
...Thomas Dietinger: die von Ihnen erwähnten nach aussen gerichteten Organisationsaufgaben werden vollumfänglich vom PO wahrgenommen. Genau das ist seine Aufgabe. Der PO ist wie der Geschäftsführer einer kleinen GmbH.

...Oliver Lehmann: die von Ihnen erwähnte Aufteilung 1/3 zu 2/3 halte ich für falsch. Alleine schon aus einer Befragung würde ich so etwas nicht schliessen. Aber ich bin mit Ihnen auch der Meinung, dass sich agile Vorgehensmodelle keinesfalls für alle Vorhaben eignen. Ich emfehle hier die Anwendung des Cynefin-Framework, mit dessen Hilfe klar ersichtlich ist, wo agil anzuwenden ist und wo Wasserfall.

Bei den von Ihnen erwähnten Kundenprojekten stimme ich Ihnen zu. Es gibt hierfür Ansätze, wie z.B. der agile Festpreis. Problematisch bleibt diese Konstellation jedoch weiterhin solange, bis sich eine vertrauensvolle Zusammenarbeit zwischen Auftraggeber und Auftragnehmer etabliert hat. Bis es soweit ist, benötigt es ein gewisses Grundvertrauen, dass "dies" schon gut kommen wird. Wir dürfen jedoch nicht vergessen, dass immer noch das PM-Dreieck gilt: man kann nicht Zeit, Kosten *und* Funktionalität/Qualität maximieren. Man kann 2 davon maximieren unter der Vernachlässigung des einen Übriggebliebenen. Oft höre ich beim Vergleich Agile vs. Wasserfall genau dieses Argument. Und es gibt Auftraggeber, die alles 3 maximieren wollen - den Projektabschluss in der kürzest möglichen Zeit zu den geringsten Kosten mit maximalem Funktionsumfang. Das war im Wasserfall falsch und im Agilen ist es immer noch falsch.

...Thilo Becker: der Agile Lead ist eine Rolle, über die wir in unserem Unternehmen bereits oft diskutiert haben, aber letztendlich ohne zur Überzeugung gelangt zu sein, dass es ihn tatsächlich benötigt. Wir kommen mit den klassischen Rollen PO und SM sehr gut voran. Der AM stiftet nur wieder mehr Verwirrung, da es grosse Überschneidungen zum SM gibt. Und: Empowerment des Teams ist eine selbstverständliche Voraussetzung dafür, dass Agile überhaupt funktioniert.

Mario, ich hoffe, ich habe nicht noch mehr Verwirrung gestiftet.
Dein ehemaliger HP-Kollege Alex

Ich finde den Artikel gut als Basis für die Diskussion! Es enthält viele Punkte, welche meiner Meinung nach durchaus gerechtfertigt sind, andere denke ich sind situativ zu beurteilen und können nicht in allen Projekten über denselben Kamm geschert werden. Und dann gibt es noch die hybriden Modelle, welche - zumindest in meinem Umfeld - immer mehr zum Zuge kommen, weil es halt immer noch Komponenten gibt, die nicht rein agil arbeiten können.
Ich denke es ist wichtig zu analysieren, wie die Hauptstakeholder funktionieren und ob die Organisation überhaupt fähig ist, agil zu arbeiten. In den meisten Fällen hat es für mich dazu geführt, dass ich dann eine hybride Organisation eingeführt habe und diese als Projektleiter dann prima führen und kontrollieren konnte, und gleichzeitig doch einige Vorteile aus der agilen Welt mitnehmen konnte.