Delivering twice the value at half the cost

Bild: Flickr / Peter Linke - CC0 1.0

Einmal mehr hat sich der bekannteste Sales-Pitch von Scrum beinahe unbemerkt geändert. Bereits 2018 schwenkte Jeff Sutherland, der Verfasser von Doing twice the work in half the time um auf Delivering twice the value in half the time, aber auch das ist mittlerweile nicht mehr der neueste Stand. Der ist seit gestern Delivering twice the value at half the cost. Man kann das begrüssen, ähnlich wie die letzte hat auch diese Neuformulierung das Potential weniger missverständlich zu sein.

Da die bisherigen Formulierung nur in ihrem hinteren Teil verändert wurde soll es hier nur um den gehen (zum ersten Teil siehe hier), und zwar zunächst um die alte Version. Liefert Scrum tatsächlich in der Hälfte der Zeit? Die Antwort: nicht zwingend, genau das ist es was missverständlich ist. Ein Vergleich der unterschiedlichen Ansätze zeigt warum.

Zuerst zu Scrum: sein Anspruch ist, durch bessere Strukturen und Prozesse in kurzer Zeit lieferfähig sein. Zum einen bedeuten crossfunktionale Teams weniger Übergaben und weniger Koordinationsaufwand, zum anderen kann die Integration der Abnahme-, Integrations- und Regressionstests in jeden einzelnen Sprint die vor dem Projektende stattfindende Integrations- und Bugfixing-Phase entfallen lassen. Zusätzlich verhindert das schnelle Beheben der Fehler, dass diese sich gegenseitig verstärken und dadurch aufwändiger zu beheben sind. So verkürzt sich die Gesamtlaufzeit, wodurch das ursprüngliche Versprechen in half the time zustande kam.

Auf der anderen Seite stimmt aber auch: klassisches Projektmanagement kann "ambitionierte Lieferfristen" ebenfalls immer wieder erreichen, und zwar mit einer einfachen Massnahme. Diese besteht darin, dass zur Erreichung der gesetzten Ziele mehr Personal in das Projekt gepumpt wird¹. Mit mehr Leuten kann dann versucht werden mehr zu schaffen, entweder durch parallele Arbeit gleichartiger Teams oder durch ein überlappendes Vorgehen der Teams die den unterschiedlichen Phasen zugeordnet sind. Es bleibt daher die Frage - wenn beide Ansätze schnell liefern können, macht der Umstieg auf Scrum überhaupt einen Unterschied?

Dass die Antwort darauf Ja ist liegt in den entstehenden Kosten begründet. Die Faktoren die in Scrum zu schnellem Arbeitsfortschritt beitragen sind im Gegensatz zum klassischen Projektmanagement nicht mit zusätzlichem Personalaufwand verbunden. Da dieser aber gleichbedeutend mit zusätzlichen Ausgaben ist bedeutet das, dass die Entwicklung im Vergleich billiger ist. Für praktisch jedes Vorhaben dürfte das ein wesentliches Argument sein, das Budget ist schliesslich in jedem Vorgehen ein entscheidender Faktor. Und damit erklärt sich auch die Sinnhaftigkeit der neuen Formulierung Delivering twice the value at half the cost.


¹Dass dieses Vogehen zu anderen Problemen führen kann ist nochmal ein Thema für sich