Das Management in Scrum

In klassischen phasenorientierten Projekten wissen die Auftraggeber in Organisationen „genau“, was sie erhalten möchten. Das Lastenheft beschreibt dies ausführlich und ganz genau auf vielen hundert Seiten – bis zum ersten Change Request. Die Zeit und das Budget sind dabei flexibel. Aber natürlich gibt das niemand zu, schließlich existieren „sportliche“ Projektpläne und das Budget sind „knallhart kalkuliert“. Wenn Sie bei dieser Hypothese Widerstand verspüren, fragen Sie sich einfach mal, wie viele Projekte Sie erlebt haben, die in Time & Budget abgeschlossen wurden. Wenn Ihre persönliche Erfahrung mit aktuellen Erhebungen übereinstimmt, sind es weniger als 10 %.

Ungewissheit gibt es immer schon

Es ist gar nicht notwendig, einen „Wir müssen jetzt aber unbedingt…“-Satz zu formulieren, da es in der Natur der Sache liegt, dass Dinge in einem Projekt nicht nach Plan verlaufen. Die Cone of Uncertainty beschreibt dieses Phänomen sehr gut. Bei der ersten Schätzung zu Beginn eines Projektes ist es natürlich, sich um den Faktor 4 zu verschätzen. Das bedeutet, dass wir massiv über- oder unterschätzen. Bei einer „Kalkulation“ von 5 Mio. EUR ist eine Bandbreite von 1,25 Mio. EUR bis 20 Mio. EUR möglich. Solche Kalkulationen beinhalten eine Scheingenauigkeit, die irreführend und ökonomisch hochgradig gefährlich sind – vom konzernpolitischen Schönrechnen gar nicht zu sprechen. Das ist der sogenannte Wassermelonen-Effekt bei Projekten: außen grün und innen rot.

Durch die starren Phasen im klassischen Wasserfallvorgehen ist das Produkt oder die Software darüber hinaus nicht im Geringsten nutzbar, ohne dass die letzte Phase abgeschlossen ist. Ganz anders mit Scrum! Scrum arbeitet iterativ und inkrementell. Das bedeutet, dass in kurzen Zyklen (zwischen einer Woche und einem Kalendermonat) ein funktionierendes Produkt bzw. funktionierende Software geliefert wird und die Lieferungen aufeinander aufbauen. Das vollwertige Produkt entsteht nach und nach, ist jedoch zu jedem Zeitpunkt nutzbar und wertstiftend.

Wann das Produkt fertig ist, entscheidet der Kunde im Laufe des Prozesses. Der Scope ist also variabel. Wenn Scrum-Teams auf diese Art (End-to-End) funktionierende Produkte liefern, und Projektkalkulationen bei der Wasserfallmethode ohnehin meilenweit daneben liegen, dann könnte man den Teams doch genauso ein gewisses Budget und einen zeitlichen Rahmen geben – also Time & Budget wirklich fixieren – und sich bei der Lieferung überraschen lassen. Ein radikaler Ansatz und dennoch macht er Projekte deutlich kalkulierbarer, als es der Wahnsinn ist, der Jahr für Jahr geschieht. Und durch Planungsinstrumente wie Story Mapping ist auch die Transparenz und Planung gegeben, damit Agilität nicht in Anarchie mündet.

Empirisches Projektmanagement

Das Ironische an diesem radikal anderen Vorgehen ist, dass das Risiko durch Transparenz und Feedbackmöglichkeiten verringert wird. Denn der Umfang für jeden Entwicklungszyklus ist einsehbar und nennt sich Sprint-Backlog. Das Sprint Review am Ende der Entwicklungszyklen dient dazu, das funktionierende Produkt zu präsentieren, ausprobieren zu lassen und Feedback einzuholen – dieses Meeting bzw. Event (im Sinne von Infotainment) ist öffentlich und kann und soll von Kunden, Nutzerinnen und Nutzern, Management und allen erdenklichen Stakeholdern besucht werden.

Bei einer Laufzeit von zwölf Monaten und zweiwöchigen Sprints wird der Deming-Cycle (Plan-Do-Check-Act), das empirische Prozesskontrollinstrument, das Scrum zugrunde liegt, bis zu 26 Mal durchlaufen: Es gibt 26 Sprint Plannings, 26 Sprint Reviews und somit 26 Mal die Möglichkeit, korrigierend einzugreifen.

Mut und Freiräume

Das Management braucht hierzu vor allem einen der fünf Scrum-Werte: Mut – den Mut sich auf dieses empirische Vorgehen einzulassen und den Mut, nicht mehr als Feuerwehr zu agieren.

Was geschieht mit der freigewordenen Zeit? Darin öffnet sich der Raum für visionäres Arbeiten, losgelöst vom taktischen Tagesgeschäft, und für echte Führung. Darüber hinaus sind ScrumMaster und Management in der Lage eine Allianz zu bilden, bei der das Management gemeinsam mit dem ScrumMaster die Impediments beseitigt, die das Team am Liefern hindern und die nicht auf Teamebene gelöst werden können – für deren Lösung Netzwerk, Erfahrung und „Schulterklappen“ hilfreich sind.

Titelbild: Unsplash License, Krakenimages