In seinem Buch “Scrum – The Art of Doing Twice the Work in Half the Time” erzählt Jeff Sutherland ziemlich am Ende eine interessante Geschichte zur Vertragsgestaltung: Auftraggeber und Auftragnehmer vereinbaren ein Auftragsvolumen. Der Auftraggeber hat das Recht, das Projekt jederzeit zu beenden, sobald er mit der Lösung zufrieden ist. Die Differenz des offenen Auftragsvolumens wird im Verhältnis 80 zu 20 geteilt. Der Auftraggeber spart somit 80 Prozent des offenen Auftragsvolumens und der Auftragnehmer bekommt 20 Prozent des offenen Auftragsvolumen als Bonus für die geleistete Arbeit.
Ein Beispiel: Ein Konzern beauftragt ein Softwareunternehmen damit, eine App zu entwickeln. Hierzu wird ein Vertrag über 12 Monate mit einem Auftragsvolumen von 1.000.000 EUR geschlossen, der im Januar startet. Im Herbst ist der Konzern glücklich mit der App und beendet das Projekt. Bisher wurden vom gesamten Auftragsvolumen erst 780.000 EUR verrechnet. Zum Projektende sind also noch 220.000 EUR offen. Hiervon bekommt das Softwareunternehmen einen Erfolgsbonus in Höhe von 20 Prozent oder 44.000 EUR. Der Konzern ist happy und spart sich die restlichen 80 Prozent, also 176.000 EUR.
Welcher ist aber der beste Zeitpunkt, um ein Entwicklungsprojekt zu beenden?
Was ein abnehmender Grenznutzen ist, wissen wir alle. Wer schon einmal an einem heißen Sommertag einen Ausflug mit dem Rad gemacht hat, kann sich vielleicht an das Gefühl erinnern, aus großer Entfernung ein Wirtshaus zu sehen, dort kurze Zeit später anzukommen, sich ein Radler zu bestellen und dieses genüsslich zu trinken. Der Grenznutzen ist hoch. Beim zweiten ist er noch signifikant, nimmt jedoch schon ab. Irgendwann tendiert der Grenznutzen gegen Null und ab einem gewissen Punkt kann der Grenznutzen auch negativ werden. Was ein negativer Grenznutzen in dem Wirtshausbeispiel bedeutet, darauf möchte ich an dieser Stelle nicht näher eingehen. Für das Projekt bedeutet ein negativer Grenznutzen, dass der Mehrwert für das Business geringer wird, als das, was an Ressourcen hineinfließt. Und genau das ist dann der Zeitpunkt, an dem es sinnvoll ist, ein Projekt zu beenden.
Klassische Werkverträge erschweren die agile Softwareentwicklung, weil sie in der Regel auf die rigide Erfüllung eines Plans ausgerichtet sind, nicht auf nutzerzentrierte Produkte (lesen Sie auch: „Übler Cocktail: Agilität und Werkverträge“). „Split the Difference“ ist ein Weg, wie Sie klassische Verträge agiler machen können.Was denken Sie über Vertragsmodelle in der Agilität? Ich freue mich über Ihr Feedback hier oder auf Social Media und lade Sie herzlich zu unserem remote Meetup am 26. November ein.Bild: Pexels License, Cottonbro