Warum es kein agiles Projektmanagement gibt! Teil II einer kritischen Auseinandersetzung.

In dieser dreiteiligen Artikelserie behandle ich zwei Arbeitshypothesen, die von mir als Fragen formuliert werden:  Gibt es tatsächlich agiles Projektmanagement? und Können wir unseren Auftraggebern allen Ernstes versprechen „Totale Agilität“ einzuführen? Im ersten Teil wurden von mir drei Frames (Prince2©, ITIL© und Scrum) gegenübergestellt, um meine erste Conclusio zu formulieren: Scrum, worauf meine Praxiserfahrung beruht, ist eine Developement-Frame mit Sicherheit aber keine Projektmanagementmethode per se! Derzeit herrscht am Markt eine babylonische Sprachverwirrung über Agilität vor. Sie ist zumal Mitursache für finanzielles Scheitern von Scrum-Developements. Wie ich zu zeigen versuche, ist Scrum als Methode überhaupt nicht in Frage zu stellen. Wenn es um Disziplin und Struktur geht, dann ist eine Scrum-Factory ein Vorzeigemodell für Daily-Business-Disziplin.

Die ersten Friktionen entstehen jedoch dann, wenn Projektleiter entweder keine Business Cases rechnen können, müssen, oder Ihre vom Business gelieferten Business Cases nicht detailliert hinterfragen. Bei reiner Budgetorientierung kommt effektiv der Tag an dem es heißt: „Fachbereich du muss priorisieren. Wir können nicht mehr alles machen, denn der Scrum neigt sich dem Ende zu und money is over.“

Hierfür ist meiner Meinung nach die Ursache, dass Scrum-KPI’s nicht in ein All-Over-Betrachtungsmodell miteinfließen. Scrum oder ein V-Modell benötigen spezielles KPI-Set-Up und zwar solche, die sich nicht ausschließlich auf den systemimmanenten Prozess konzentrieren. Ich gestehe offen ein, dass ich mir meine Zähne selbst oft genug ausgebissen habe. Diese an sich simple Anforderung ist alles andere als einfach bei den Stakeholdern durchzubringen. Von alteingesessenen Führungskräften, ganz zu schweigen. Ken Schwaber von scrum.org meint hierzu sehr treffend: „Scrum is not the answer. Scrum is an enabler“.

Scrum-Factories und Projektcontrolling

Bekanntlich werden in Scrumteams Risiken in den jeweiligen Sprints gelöst. Zuallermeist sind das Risiken im application developement life-cycle. Der agile IT-Projektmanager ist vielleicht auch Product Owner. Zuerst einmal ist er daher daran interessiert, dass die überschaubaren Developement Life Cycle Risks in den Sprints vom Team behoben werden. Sein oberstes Ziel ist die möglichst userfriendly Umsetzung der Business Requests durch sein von ihm aufgebautes Team. Übrigens habe ich die Erfahrung gemacht, dass extern gestaffte Scrum Factories um einiges besser funktionieren als reine Inhouse-Teams. Wenn das Budget knapp wird, stellt der IT-Projektmanager einen Change Request an seine Stakeholder. Den Business Case den vielleicht die Aufbauorganisation gerechnet hat, kennt er wahrscheinlich gar nicht, sondern nur seinen Budgetrahmen. Aber angenommene cost savings durch das Scrum-Developement können eventuell bereits mit einem einzigen Change Request nicht mehr eingefahren werden. Die Grafik veranschaulicht auf simple Weise einen „klassischen“ Risikoverlauf einer Scrum-Factory. Eines der Risiken ist dabei die Nichteinhaltung von Budgets.

Der Risikoverlauf potenziert sich, wenn mehrere parallellaufende Scrum-Factories nicht in eine Projektcontrolling-All-Over-Sicht miteinbezogen werden. Soweit ich sehe, schlagen die Apologeten der einzig seligmachenden Agilität derartige Betrachtungen kaum vor. Selbst wenn ein Lippenbekenntnis zu Scrum vorhanden ist, erhält der IT-Projektmanager oder Product Owner häufig nicht das Gewicht eines entscheidungsrelevanten Stakeholders. Mit ein Grund dafür ist, dass er üblicherweise Budgets verwaltet, aber nicht gestaltet. Diesbezüglich wird der eherne Begriff des Scrum-Frames „Kundenorientierung“ von PM’s mitunter recht eigentümlich interpretiert.

Als ein auf Multi-Project-Management spezialisierter PM der agile, waterfall oder Lean Management Developements zumeist in die Gesamtprojektplanung miteinzubeziehen hat, da in Enterprises sehr oft, und nur davon kann ich reden, alle drei Frames parallel zu managen sind. Darauf aufbauend betrachte ich Scrum-Factories, Vendoren, Prozesse, etc. als gestaltbare Cost Center und nicht als gegebene Budgetposten. Gleiches gilt für das Riskmanagement. Zu jedem Cost Center wird eine Riskmatrix entwickelt. Auch jeweils eigene Cost-Center-KPI’s werden designt. Auf Basis dessen kann dynamisch gesteuert werden. Aber ist das Agilität? Oder ist das „normale“ Projektmanagementmethode? Ich weiß es nicht – jedenfalls aber mein Erfolgsrezept. Dies aus gutem Grund, denn einer der folgenschwersten Irrtümer über Agilität ist, nur, weil vom Scrum Master keine Risks aus der Scrum-Factory gemeldet werden, dass auch beim Budget alles in Butter sei. Der auf den Fuß folgende Realitäts-Aufschlag kommt dann, wenn der Scrum Master dem Product Owner oder IT-Projektmanager meldet: „Stockt bitte das Budget auf, ansonsten bleiben wir auf derzeitigem Entwicklungsstand stehen. Wir können ohne On Top Budget nicht weiterentwickeln“. Mit sehr hoher Wahrscheinlichkeit folgt noch der Satz: „Der Endkunde, die Abteilung xy, wird so nicht zufrieden sein.“ Häufig genug bin ich daran schier verzweifelt, bis ich die beschriebene Herangehensweise umzusetzen begann. Der Vorteil dieses am Beginn sehr aufwendigen Verfahrens ist, dass ich alle wichtigen Kennzahlen sofort abrufen kann. Ansonsten ist auf die Anforderung des Scrum Masters eine Entscheidung, zwischen Pest oder Cholera zu treffen. In diesem Zusammenhang ist es egal, wenn beispielsweise Scrum als Developement-Lösung für ein klar definiertes Produkt zur Anwendung kommt. Das entwickelte Produkt steht dann ja nicht allein in der Welt herum, sondern steht beispielsweise in Zusammenhang mit Prozessen, Salesaktivitäten, organisatorischen Änderungen, usf. Warum sollte es hier nicht gleich wichtig sein, ein All-Over-Controlling zu modellieren?

Die babylonische Begriffsverwirrung

Hat ein PM ein Mandat inne bei dem es darum geht mit agilen Methoden IT Services zu implementieren, stößt jener agilwillige PM auf den ersten Blick zumal auf unüberbrückbar erscheinende Gegensätze zwischen Enterprise-Alltag, Fachbereichs-Requests, Stakholdermanagement und „reiner“, agiler Projektmanagementmethode. Diesen Brückenschlag zur Vereinigung des „Besten aus allen Welten“ kann es gar nicht geben. Auch wird er lange danach suchen was denn agile Businessprozesseinführung sein soll. Auch diese gibt es schlichtweg nicht. Eine Umsetzung in Steps entlang einer Roadmap bis hin zum E2E-Sollprozess ist noch lange kein agiles (Projekt-) Prozess Management. In einer Diskussion meinte ein Kollege einmal:

AgilePM hingegen verbindet auf einfach homogene Weise seit 1995 beide Welten. Agiles Produkt- und Projektmanagement. Darüber gibt es sogar agiles Programmanagement. Ganz dogmatisch sauber betrachtet, wären rigide scheinbare Gegensätze nie vereinbar. Mit einer anderen Haltung und weg von irgendwelchen eingegrabenen Kerben ist so vieles erreichbar.

Kanban spricht (D. J. Anderson) von „a new technique for managing a software development process in a highly efficient way“ gesprochen wird.

Was gilt nun? Agiles Programm-Management oder agile Software-Entwicklung oder doch beides zusammen? Modelle über agiles Programm-Management stellen uns sehr gute Rollen,- u. Organisations-Umstrukturierungs-Matrizen vor. Jedoch bleibt Projektcontrolling auf dem Weg zur „Agilität-Total“ einzig und allein auf inkrementelle Sprints beschränkt. Selbst agile Skalierung wird der Organisation als agiles Erfolgsmodell angeboten. Wir sind einer Meinung darüber, dass es agile Skalierung in Scrum gibt. Nur frage ich mich, wenn ich sieben, acht Scrumteams als Product Owner oder PM steuern soll, wie ich ohne Gesamtprojektplan, E2E Betrachtung und Riskmanagement auskommen soll, oder anders gefragt, was genau soll hier Agilität recht eigentlich sein und leisten können?

Es geht mir also nicht um die Frage nach der „richtigen“ Methode, oder um die Frage nach dem „richtigen“ Frame, oder schon gar nicht um eine Skalen-Bewertung der einen oder der anderen Herangehensweise, sondern einzig um klare Definitionen und notwendige Begriffsabgrenzungen. Eine Produktentwicklung lässt sich selbstverständlich mit agilen Ansätzen zum Erfolg führen. Selbst eine so genannte „organisatorische Neuausrichtung“ auf „Scrum-Total“, wie unwahrscheinlich mir das auch vorkommt, wäre, wenn nur die Scrum Teams betrachtet werden, vielleicht möglich. Ein kleines Praxisbeispiel: Derzeit stehe ich der spannenden Fragestellung gegenüber, wie ohne hohe Investments bestimmte Applikations-Developments, besser getrackt werden können. Zum einen wird eine zu lange Produktionszeit bemängelt, zum anderen scheint noch niemand ernsthaft daran gedacht zu haben, diese speziellen Entwicklungs-Bereich auf mehrere Scrum-Factories umzustellen, um so optimaler Tracken zu können. Dieses Tracken müsste unter Projektcontrolling-Regeln erfolgen. Wenn es mir gelänge diesen Vorschlag tatsächlich durchzubringen, könnte wir dann wirklich behaupten, dass, nur, weil ein paar Scrum Factories als kontrollierbare Effizienzbringer eingeführt haben, wir gleichzeitig „agiles Projektmanagement“ eingeführt hätten? Eher meine ich, solange die Factories nicht in ein KPI, Risk und Business Case getriebenes Controlling überführt werden, haben wir wahrscheinlich eher ein paar freie Radikale geschaffen.

Nicht nur Projekte, sondern auch Innovationen sind letztlich ein Gambling mit unbekannten Variablen, welches man sich zuerst einmal leisten können muss. In diesem Zusammenhang wird eine Umstellung auf „Agilität-Total“ oftmals als alleinseligmachende Weisheit der Effizienz,- u. Finanzkontrolle propagiert. Da ich das nicht so sehe, ist mein Anspruch in Karl R. Poppers prägnanten Worten ausgedrückt:

Nur Falsifizierung führt zu neuen Erkenntnissen.