Es war einmal vor langer Zeit in einer weit, weit entfernten Galaxis… Die Unternehmen brauchten eine wirkungsvolle Form des Projektmanagements und stritten sich, ob klassische Wasserfallmethoden oder das agile Projektmanagement besser seien. Wird dieser Beitrag die Macht wieder ins Gleichgewicht bringen? Ich versuche es einfach mal.

Beginnen wir beim Imperium, dem klassischen Projektmanagement:

Der klassische Projektmanager plant zu Beginn eines Projektes, und zwar das gesamte Projekt – genauso wie Palpatine seit langem geplant hat, die Galaxis zu erobern und als Imperator zu führen. Der Imperator ist in unserer Allegorie der Projektauftraggeber, die höchste strategische Ebene im Projekt (in der Praxis natürlich meist durch einen Lenkungskreis unterstützt, aber ein Imperator entscheidet lieber alleine). Der Projektmanager ist derjenige, der für die Erreichung des strategischen Planes hauptverantwortlich ist, der operative Planer, derjenige, welcher dem Imperator dabei hilft, seinen Plan zu realisieren und selbigem gestattet, etwas im Hintergrund zu bleiben und nur bei Eskalationsbedarf Machtblitze zu schleudern. Zum Bau des Todessterns war der Projektmanager: Daa daa dah da da daah da da daah  Darth Vader.

Aus Sicht der imperialen Unternehmensführung ist das bequem: Es existiert eine Person, welche greifbar ist, und deren Erfolg an von dieser Person selbst definierten Solldimensionen gemessen werden können. Diese Denkweise passt sehr gut ins klassische Hierarchiedenken des Imperiums, Befehle fließen von oben nach unten, Informationen von unten nach oben – eine klar strukturierte Welt mit im Zweifelsfall klar definierten Schuldigen.

Unter welchen Bedingungen funktioniert das? Der Plan steht und fällt natürlich mit der Fähigkeit des Planers zu planen. Das für- und wieder dieser Problematik diskutierte Anakin Skywalker mit Padmé Amidala in „Angriff der Klonkrieger“ auf Naboo, bevor er zu Darth Vader wurde: Wenn es den einen weisen Führer gäbe, der über vollständige Informationen und somit über vollständige Planungssicherheit verfügen würde, und der dazu noch zwischenmenschlich verständnisvoll handelt und agiert, dann wäre das Imperium ein toller Ort und klassisch geführte Projekte würden immer funktionieren – das ist aber nun mal beides nicht der Fall.

Ein Trost für den Imperator: Im klassischen Projektmanagement ist wenigstens der Projektmanager für das Gelingen des Projektes verantwortlich, bei Verzögerungen oder Scheitern ist somit immerhin klar, wer gemachtblitzt oder machtgewürgt werden kann. Für weitere Bedingungen, unter denen das klassische Projektmanagement funktioniert, steht Ihnen die vielzitierte Stacey- Matrix zur Verfügung, ich belasse es an dieser Stelle erstmal dabei.

Kommen wir zum agilen Projektmanagement, den Rebellen im Imperium der Projektmanager:

Die Rebellen agieren zunächst freiwillig, aus eigener intrinsischer Motivation heraus innerhalb kleiner Zellen. Das sind zufälligerweise die typischen Voraussetzungen, unter denen das agile Projektmanagement funktioniert und das ist der wesentliche Unterschied zum Hierarchiedenken des Imperiums: Interdisziplinäre Teams können selbst und weitestgehend demokratisch entscheiden. Der Scrum – Master ist der Servant – Leader, auf Seiten der Rebellen darf also nicht gemachtblitzt werden. Der Product – Owner gibt Aufgaben vor, das Team entscheidet selbständig, bis wann die Pläne des Todessterns gestohlen werden können (bzw. müssen) und welche Vorarbeiten dafür notwendig sind.

Ist das besser? Der Vergleich des Imperiums vs. Rebellen legt dies an dieser Stelle nahe, aber ich gebe zu, dass der Vergleich hier nicht so eindeutig ist, wie es scheint:

Die Fähigkeit des Teams, gute Entscheidungen zu treffen, basiert auf der Annahme bzw. auf dem Menschenbild, dass das Team gute und fundierte Entscheidungen treffen kann. Ein Team voller Idioten wird demnach trotz der demokratischen Entscheidungsgrundlage idiotische Entscheidungen treffen oder anders ausgedrückt: Ein Team voller Imperatoren wird das Imperium nach erfolgreicher Rebellion wieder in ein Imperium zurückführen und gegeneinander um die Alleinherrschaft kämpfen. Der Imperator ist tot, lang lebe der Imperator! Nun ist die Wahrscheinlichkeit, dass ein ganzes Team voller Imperatoren existiert wesentlich geringer als jene, dass ein einzelner Imperator ein Idiot ist, aber der Demokratie reicht auch schon eine Idioten- Mehrheit von 51%, um sie ins Verderben zu stürzen.

Ebenfalls ist die beschriebene Einheit eines Teams recht leicht in kleinen Teams erreichbar – schwierig wird es, wenn die Sache größer wird und mehrere Teams zusammen arbeiten müssen. Das zeigt die Geschichte der Rebellen eindrucksvoll am Beispiel der Fliegerasse Cassian Andor und Poe Dameron, die beide erhebliche Probleme damit haben, Befehlen zu folgen und dadurch Probleme bekommen.

Befehle? Welche Befehle? Steht da nicht, dass agile Teams sich selbst organisieren? Ja, das steht da und das ist auch so gedacht. Am Anfang der Rebellion war es ausreichend, wenn einzelne Zellen lose und selbstbestimmt zusammen arbeiteten, je größer die Sache jedoch wurde, umso mehr hat sich auch bei den Rebellen eine Befehlsstruktur etabliert, jener des verhassten Imperiums nicht unähnlich, nur halt ohne Machtblitze, dafür mit humaneren Bestrafungsmechanismen, denn wo Befehle existieren, existiert zwangsläufig Ungehorsam.

Ein guter Einblick in diesen Widerspruch lässt sich anhand des Werdegangs von Prinzessin Leia Organa darstellen: Sie hat als engagierte, idealistische Rebellin in mit ihrem kleinen Scrum-Team begonnen, wurde zur Rebellenführerin und hat jene hierarchischen Strukturen maßgeblich mit etabliert, welche ihr den Zorn und den Ungehorsam von Poe Dameron entgegengebracht haben. Diesen Werdegang teilt Leia Organa mit einigen der Rebellenführern, welche in einer Skihütte auf dem Planeten Utah das agile Manifest entwickelt und unterzeichnet haben: Damals waren sie Softwareentwickler, heute sind viele von ihnen CIOs oder CEOs von ihren eigenen oder anderen Unternehmen. Manche dieser Rebellenführer haben sich übrigens mittlerweile von ihrem Manifest distanziert, weil sie in der Praxis damit bemerkt haben, dass das agile Arbeiten zwar einige der Probleme des klassischen Projektmanagements wie gewünscht löst, dafür jedoch an anderer Stelle Probleme verursacht. Letztendlich existiert keine Medizin ohne Nebenwirkungen.

Apropos Probleme: Eine weitere Beschränkung der agilen Arbeitsweise wird aus dem obigen Beispiel ersichtlich: Die Zusammenarbeit von vielen Teams oder vielen Menschen. Das ist im SCRUM nicht vorgesehen. Die Referenzsituation für SCRUM ist: Ein Team entwickelt ein Produkt – SCRUM ist daher auch streng genommen eher ein Produktmanagement – Framework als ein Projektmanagement – Framework. Dieses Problem versuchen unterschiedliche Ansätze auf unterschiedliche Arten zu heilen: SAFe, LeSS, Spotify – mit unterschiedlichem und individuellem Erfolg.

Kommen wir zur Synthese und zum Fazit, bevor wir in den Details der Methoden und der Star Wars Galaxis versinken:

agile Methoden basieren auf einem modernen, positiven und erstrebenswerten Menschenbild, nämlich dem der Mündigkeit und der Fähigkeit sowie dem Wunsch zur selbstbestimmten Arbeitsweise. Sofern die Menschen in Ihrem Team dieses Bild erfüllen, ist die grundlegende Prämisse zur Einführung agiler Methoden gegeben. Wenn Ihr Unternehmen klein und jung ist, beispielsweise in einer Startup- Situation, wird SCRUM höchstwahrscheinlich funktionieren. In größeren Unternehmen, Imperien, um bei dem Beispiel zu bleiben, besteht zusehends die Gefahr, dass „Agil“ zu „Chaotisch“ wird. Auch die Rebellen benötigen mit wachsender Macht und wachsender Personenanzahl wachsende Strukturen, um sich verwalten zu können (Corporate Governance, Projekt- und Portfolio- Governance sowie  Prozessmanagement sind hier wesentliche Methoden). In einer solchen Situation macht es mehr Sinn, sich zum klassischen Projektmanagement hin zu entwickeln oder die angesprochenen Skalierungs – Frameworks für agile Methoden auszuprobieren. Ebenfalls wichtig ist, ob ein Spielraum existiert, lustig vor sich hin zu iterieren, bis das Produkt dann mal fertig ist, oder ob ein dringender Endzeitpunkt existiert, beispielsweise aufgrund von rechtlichen Zwängen. In ersterem Fall kann agiles Projektmanagement angewendet bzw. ausprobiert werden, in letzterem Fall wäre es ratsam, klassisches Projektmanagement anzuwenden.

Die beste Erfahrung habe ich mit hybriden Projektmanagement gesammelt: Das beste aus beiden Welten vereinen, um Projekte zum Erfolg zu führen. Die Fragestellungen dazu sind: Wo steht die Firma gerade? Wie selbstbestimmt können/ möchten die Kollegen arbeiten? Wieviel Reporting wird gewünscht? Wie wichtig ist ein fixer Endtermin und eine fixe Kostenkalkulation für das Projekt? Ist das Team (be)fähig(t), sinnvolle eigene Entscheidungen treffen zu können?

Auch wenn nach Beantwortung der obigen Fragen das Barometer mehr in Richtung agil ausschlägt, würde ich Methoden des klassischen Projektmanagements zu Beginn des Projektes anwenden: Stakeholderanalyse, um eine Kommunikationsmatrix zu erstellen und um keine wichtigen Stakeholder im Projekt zu vergessen, Risikoanalyse, um Gegenmaßnahmen zu entwickeln und eine Zieldefinition, um Scope- Creep zu vermeiden. Die Methoden können auch innerhalb eines Projektes gemixt werden – ich habe gute Erfahrungen damit gesammelt, Testphasen zu agilisieren mit Daily – Standups und schneller Problemlösung, um sich nicht zu sehr in Details zu verirren und um die Kommunikation bereichsübergreifend zu stärken. Bei der Führung mehrere Dienstleister, bei welchen ein Teil klassisch arbeitet und ein Teil agil, kann ein klassischer Projektablaufplan erstellt werden. Der agile Teil kann dann innerhalb der Phasen sprinten – auf diese Weise können beide Sichtweisen parallel innerhalb eines Projektes vereint werden.

Wie sind Ihre Erfahrungen mit klassischen und agilen Projektmanagement? Fallen Ihnen weitere Anwendungsvoraussetzungen  für die beiden Methoden ein? Welche Methoden wenden Sie am liebsten an, wie kombinieren Sie diese? Welchen Star Wars Charakter mögen Sie am liebsten und arbeitet er eher agil oder klassisch?