15 Jun
Agiles Projektmanagement Scrum

Projektmanagement vs. Scrum

Seitdem der Begriff ‚agiles Projektmanagement‘ aufgetaucht ist, gibt es eine fortwährende Diskussion über das Verhältnis von etablierten Projektmanagement Methoden (PMM) wie zum Beispiel PRINCE 2 oder PMI zu SCRUM als ein Vertreter der agilen Projektmanagement Methode. Dieser Artikel betreibt etwas Projektmanagement Methodologie, ist also ein kleiner Beitrag zur Lehre der Projektmanagement Methoden (PMM).

SCRUM IST GAR KEINE PROJEKTMANAGEMENT METHODE

Die Frage die sich mir stellt ist nicht, wie gestaltet sich das Verhältnis von SCRUM zu z.B. PRINCE 2, also wie ist das Verhältnis zwischen SCRUM und traditionellen PMM, sondern ob SCRUM überhaupt eine PMM ist, wie der Überbegriff ‚agiles Projektmanagement‘ nahelegt. Warum ist das wichtig?

Unternehmen sehen sich oft genötigt, bei der Abwicklung von Projekten sich für eine bestimmte Methode zu entscheiden. Oft ist dies sogar eine Frage von Konzern-Compliance-Richtlinien. Unternehmen, die SCRUM gerne einsetzen möchten meinen, sie müssten sich entscheiden und Ihr geliebtes PRINCE 2 über Board werfen, bzw. Ihre Compliance-Richtlinien ändern. So ein Unterfangen ist für große Konzerne alles andere als ein Spaziergang sondern gleicht eher einem Jakobsweg. Was aber, wenn dieser Jakobsweg gar nicht gegangen werden muss weil SCRUM keine PMM ist und somit auch nicht im Widerspruch zu anderen PMMs stehen kann? Es geht hier allerdings nicht darum, Unternehmen durch einen Trick einen Ausweg aus dem PMM Dilemma zu zeigen, sondern ein fundamentales Missverständnis bei der Bewertung von SCRUM als agile PMM aufzudecken.

Das gut gemeinte Ersetzen einer PMM durch SCRUM im Projekt lässt in der Regel beide als Beschädigte zurück: das Projekt, in dem wichtige Dinge nicht gemanagt  werden und welches nicht erfolgreich verläuft, und SCRUM die als PMM ob der vielen gescheiterten Projekte in Verruf gerät.

SCRUM IM PROJEKT, NICHT ALS PROJEKT

Ich sehe SCRUM als eine Software Implementierungs Methode (SIM), obwohl sich möglicherweise SCRUM auch auf andere Industriezweige übertragen lässt. Im Grunde würde ich sagen, dass sich SCRUM auf alle Prozesse übertragen lässt, die prinzipiell commitment- und completion-fähig sind. Was es genau mit Commitment und Completion auf sich hat, können SieHIER in meinem Artikel über das Wesen von SCRUM nachlesen. Als Software Implementierungs Methode (SIM) agiert SCRUM innerhalb eines Projektes, nicht anstelle des Projektes. Vereinfacht betrachtet gibt es in einem Projekt neben der Abarbeitung eines Product Backlogs sehr viele Aufgaben, die wesentlich zum Projekterfolg beitragen, von SCRUM aber nicht erfasst oder abgedeckt werden. Einige davon beginnen, wenn das Projekt bereits initialisiert ist, die Entscheidung, welche SIM (SCRUM oder Wasserfall) verwendet wird aber noch gar nicht getroffen worden ist. Dies ist eine Aufgabe des Projektmanagements. Auch die Zusammenstellung der Teams, die initiale Budgetierung, die Überwachung von Compliance-Richtlinien, das Projekt-Marketing, weite Teile des Projekt-Controllings, die über die Analyse von Burndown-Charts hinausgehen fallen in den Aufgabenbereich des PMM und nicht in den der SIM.

WAS EIN PROJEKT FÜR SCRUM TUN MUSS

SCRUM selbst kennt nur die Rollen Product Owner, Scrum Master und Scrum Team und ist damit hoch spezialisiert auf die Erstellung und Abarbeitung eines Product Backlogs. Diese Spezialisierung ist sehr effektiv auf genau diese Aufgabe ausgelegt und versagt, wenn Dinge erledigt werden müssen, die nicht in dieses Schema passen. Allgemein werden solche Dinge, wie z.B. Auseinandersetzungen mit Betriebsräten über die Zulässigkeit des Time-Trackings oder der Zuweisung von Tasks zu Personen, plötzlich abgelaufene Softwarelizenzen und deren Wiederbeschaffung von SCRUM als Impediment wahrgenommen, die den Kernprozess stören und extern gelöst werden müssen. Dafür ist das Projekt da. Das Projekt schützt die Implementierung als ihr „Allerheiligstes“, als das wahre Element der Wertschöpfung. Und dieses Projekt bedient sich dafür einer PMM und bildet den Rahmen in dem SCRUM agiert. Die Herausforderung der PMM ist, sich auf die Gegebenheiten der SIM anzupassen. Das muss sie sowieso, egal, ob Sie nach Wasserfall oder nach SCRUM implementieren. Jede SIM hat seine Besonderheiten. Niemand wäre dabei auf die Idee gekommen, Wasserfall als eine PMM zu betrachten und dieser Fehler sollte uns bei SCRUM auch nicht unterlaufen.

VON PROJEKT- UND TEAMLEITERN

Allen Projektleitern, die sich schon als Scrum Master degradiert gesehen haben bzw. sich komplett in der Überflüssigkeit wähnten, dürfte ich mit dieser Sichtweise gerade der Job gerettet haben. Spenden nehme ich dafür gerne und dankend entgegen. Bei Teamleitern stellt sich das Ganze allerdings ganz anders dar, falls Sie nicht gerade in einer Matrixorganisation leben. SCRUM baut im Implementierungsprozess ganz bewusst Bürokratie und Hierarchien ab, eliminiert Micro-Management und ersetzt sie durch eine sehr effektive Selbstorganisation crossfunktionaler Teams, die nach anderen Regeln funktionieren kann als die sich darum organisierende Projektstruktur. Sie kann sogar andere kulturelle Werte hervorbringen, die gerade aus dieser verantwortungsvollen Selbstorganisation erwachsen. Projektorganisationen sind hier gut beraten, diesen kulturellen Change zu fördern und in der Unternehmensorganisation zu vermitteln. Eine Herausforderung, die großen Konzernen oft sehr schwer fällt und Grund genug für diese, SCRUM grundsätzlich ein ungerechtfertigtes Misstrauen entgegenzubringen. Die Projektleitung muss genau dieses im Blick haben, bevor sie sich für SCRUM als SIM entscheidet.

Das Unternehmen oder auch das Projekt muss SCRUM fähig gemacht werden.

Leave a Reply

Your email address will not be published. Required fields are marked *