Ziel jeder Softwareentwicklung ist das Entstehen eines gewissen Werts. Niemand – vor allem keine Unternehmen – entwickeln Software zum Spaß (es sei denn Spaß an der Entwicklung ist der ausgesprochene Wert). Auch in einem typischen Auftraggeber Dienstleister Verhältnis geht es darum, für beide Seiten Wert zu erzeugen.
Eine WinWin Situation ist das Ziel (Gewinn 1: funktionierende Software, Gewinn 2: Umsatz) und um das zu erreichen, ist ein partnerschaftliches Verhältnis sehr förderlich, zumal – frei nach dem Motto – never change a running system – gerade eine dauerhafte partnerschaftliche Zusammenarbeit zu effektiveren und effizienteren Ergebnissen führt.
Softwareentwicklung nach Scrum kann helfen, diese WinWin Situation zu erreichen und Festpreisprojekt und Scrum müssen kein Widerspruch sein. Wichtig aber ist, dass sich beide Parteien im gegenseitigen Vertrauen und partnerschaftlich zusammenarbeiten und dass der Kunde möglichst tief im Entwicklungsprozess (zum Beispiel als Product Owner oder mindestens als aktiver Stakeholder) integriert ist. In diesem Fall lässt sich in den normalen Festpreis-Vertrag der beiden Parteien eine Ergänzung integrieren, die Jeff Sutherland und Jim Copliend als “Money for nothing, change for free” bezeichnen.
„Money For Nothing“ beschreibt die Möglichkeit des Kunden, die Entwicklung nach jedem Sprint abzubrechen. Das kann Sinn haben, wenn die zu erwartenden Kosten für die Weiterführung des Projekts höher werden, als der Wert, der dabei rauskommt. Bricht der Kunde die Entwicklung ab, fallen noch 20% des restlichen Vertragsbestandteils an Kosten für die Durchführung des Abbruchs und den finalen Projektabschluss an.
Der Dienstleister verpflichtet sich, mindestens 80% des Projektumfangs in der durch die Definition Of Done festgelegten Qualität zu liefern. Grundvoraussetzung hierbei ist, dass der Kunde selbst aktiv als (zum Beispiel) Product Owner oder mindestens als aktiver Stakeholder in dem Projekt beteiligt ist.
„Change For Free“ beschreibt die Möglichkeit des Kunden, während des Projekts von Sprint zu Sprint Änderungen einzureichen, ohne dabei zusätzliche Kosten zu haben. Änderungen oder neue Erweiterungen müssen gegen gleichwertige bestehende Aufgaben eingetauscht werden. Bei einem gut geführten Backlog mit Epics und User Stories, die nach ihrem Business Wert in eine Reihe gebracht sind, kann der Kunde so dafür sorgen, dass er das für ihn beste Ergebnis zum ursprünglich vereinbarten Budget bekommt.
Mehr Infos: Artem Martenko stellt auf seinem Blog „Agile Software Development“ 10 mögliche Verträge für ein agiles Software Projekt vor.