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 keine Projektmanagement Methode
Die Frage, die sich mir stellt, ist nicht, wie gestaltet sich das Verhältnis von SCRUM zu z.B. PRINCE 2 & Co, 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, sich bei der Abwicklung von Projekten 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 oder HERMES (in der Schweiz) ü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 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.
Als Software Implementierungsmethode (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. Darin ist keine Beschneidung der in Scrum sinnvoll geforderten Selbstorganisation der Teams zu sehen, sondern bestimmt lediglich den Scope bzw. die Reichweite dieser Selbstorganisation.
Was ein Projekt für Scrum tun muss
Scrum selbst kennt nur die Rollen Product Owner, Scrum Master und Dev-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 bzw. die Organisation 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 den 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.
Das Projekt schützt die Implementierung als ihr „Allerheiligstes“, als das wahre Element der Wertschöpfung.
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.
Scaled Agile Organisationen
Wenn Organisationen nach einigen (hoffentlich) erfolgreichen Scrum Piloten, in eine agile Transformation einsteigen, also die Absicht haben, Scrum in der Organisation zu skalieren, stellen sich natürlich neue Fragen.
Selbstverständlich ist Scrum in einer klassischen Matrixorganisation nicht im Paradies und es gibt immer wieder Reibungspunkte. Diese rühren aus dem Umstand der Scrum-Forderung nach Selbstorganisation der Teams.
Im Kern bedeutet dies, dass strenggenommen, Scrum ein nichthierarichses Modell einführt. Das Problem hier ist, dass wir als Menschen in der Regel nicht so sozialisiert sind, d.h. sowohl die meisten Gesellschaften wie auch Unternehmen hierarchisch organisiert sind.
Dieser Konflikt muss in einer Organisation gelöst werden. Daher werden Organisationen im Rahmen einer agilen Transformation früher oder später ihre PMM updaten müssen. Der aktuell erfolgreichste Vertreter einer PMM, die Scrum in die Organisation skalieren lässt, ist SAFe. Solche agilen PMMs (auch LeSS oder Nexus sind Vertreter) gehen von einer eher dezentralisierten und vertikalen Organisaiton aus.
Wann dieser Übergang von klassischer PMM zu einer agilen PMM wie z.B. SAFe vorgenommen werden sollte ist aktuell wohl eine der großen Herausforderungen von Organisationen und muss sehr sorgfältig überlegt und vorbereitet werden.
