Ist der agile Festpreis ein Oxymoron?

Oxymoron… was war das nochmal? Ach ja, genau, zum Beispiel „alter Knabe“ oder „schwarzer Schimmel“, also eine Formulierung aus zwei gegensätzlichen Begriffen. Der agile Festpreis. Das klingt nach so einem Widerspruch. Denn wie soll man etwas fixieren, das unbedingt beweglich sein soll? Ganz einfach, man schafft einen festen Rahmen, in dem der Scope variabel ist. Während im klassischen Projektmanagement der Umfang eines Projekts z.B. im Lastenheft/Pflichtenheft genau definiert ist und die Parameter Kosten und Zeit Änderungen ausgleichen müssen, steht beim agilen Vorgehen das magische Dreieck auf dem Kopf. Kosten und Zeit werden fixiert und der Scope darf variieren.

Agilität unter Vertrag

Wie schließt man solide Verträge mit Unternehmen, die agil vorgehen? Natürlich ist es toll, wenn Entwicklerteams, die nach Scrum arbeiten, schneller Ergebnisse liefern und Kundenwünsche relativ spontan wahr werden lassen. Aber als Auftraggeber möchte ich doch ganz gerne wissen, was ich wann zu welchem Preis geliefert bekomme. Als Lieferant hingegen kann ich bei ständig aufkommenden Change Requests nur schwer einen verbindlichen Preis kalkulieren. Ein echtes Dilemma. Wie gut, dass sich für dieses Problem schon eine Lösung gefunden hat: der agile Festpreis.

Kooperation und Vertrauen

Wie funktioniert dieser Kompromiss? Die Gegensätze lassen sich nur vereinbaren, wenn beide Vertragspartner konstruktiv zusammenarbeiten und mit einer „gewissen Ungewissheit“ leben können. Leider möchten manche Abteilungen in beauftragenden Unternehmen das aber nicht absegnen. Einkauf, Controlling und Management bevorzugen meist präzise Angaben über die Verwendung von finanziellen Mitteln. Ein Kulturwandel muss her, der ganzheitliche Agilität erst möglich macht. Weil so ein Mindset nicht binnen kurzer Zeit einfach so vom Himmel auf eine ganze Organisation fällt, schlägt das agile Festpreismodell einen Ablauf vor, der den vertraglichen Rahmen festlegen helfen soll. Andreas Opelt [1] et al. empfehlen diese Schritte:

1. Vertragsgegenstand grob auf Basis von Projektzielen (Vision, Themen und Epics) beschreiben.
2. Repräsentative Epic auswählen und bis zur Ebene von User Stories verfeinern. Der Lieferant nutzt das Beispiel als Analogie und erstellt eine Schätzung für das gesamte Projekt (initialer Festpreis).
3. In einem gemeinsamen Workshop von Kunde und Lieferant werden Annahmen getroffen über Aufwände des gesamten Projekts. Das Implementierungsrisiko und der Business Value werden gesamt geschätzt.
4. Zeitliche Festlegung einer Checkpoint-Phase (Testphase für die Zusammenarbeit) und Überprüfung des initialen Festpreises. Definition der Risk-Share (Finanzielle Verteilung der Kosten bei Überschreitung dieses Preises).
5. Vereinbarung von Prozessen zur Projektsteuerung, die ein Scope-Governance Team (mit Vertretern von Kunde und Lieferant) übernimmt.
6. Festlegung eines Bonus-Systems (für vorzeitige Projekterfüllung) und Finalisieren des rechtlichen und kommerziellen Rahmens.

Die ersten drei Schritte dienen der Abschätzung des Scopes. Die Schritte 4-6 legen die Prozesse zur Zusammenarbeit fest. Im Grunde geht man beim agilen Festpreis auch inkrementell vor. Man wählt exemplarisch eine wichtige (vielleicht sogar die wichtigste) Epic aus, verfeinert sie und legt einen Zeitraum für die Implementierung (z.B. 2-5 Sprints) fest. Dann wird ganz real entwickelt. Nach Ablauf der Checkpoint-Phase bewertet man das Ergebnis und entscheidet über die weitere Zusammenarbeit. Möchte man weitermachen, kann man auf Basis des Testlaufs eine Schätzung für das Gesamtprojekt vornehmen und einen Preis dafür festlegen. Im Idealfall hat man am Checkpoint dadurch schon eine wichtige Epic des Projekts realisiert und sich von der Qualität des Lieferanten überzeugt. Der Auftraggeber kauft also nicht mehr die Katze im Sack, sondern testet im Kleinen, ob das große Ganze gelingen kann. Man könnte sogar behaupten, dass ein Projekt mit einem agilen Festpreis viel weniger Gefahr läuft, komplett aus dem Ruder zu laufen, weil die eng getakteten Liefer-und Feedbackschleifen gar keine totale Fehlentwicklung zulassen. Boris Gloger schrieb dazu [2]:

Wer sich traut, auszumachen, dass der Dienstleister keine Arbeit, sondern Produktteile liefert und es innerhalb eines Projektes sehr schnell zu Änderungen kommen kann, wird damit belohnt, dass sich der Cost of Delay minimiert und der Return On Investment maximiert.

Im agilen Festpreismodell sind beide Vertragspartner gefragt, Risiken abzufedern, Anforderungen aktuell zu halten, Zwischenergebnisse zu liefern/zu testen und transparent zu kommunizieren. Kunde und Lieferant bilden sozusagen ein Team, das vertrauensvoll zusammenarbeitet. Diese „kulturellen Requirements“ könnte man zum Beispiel in einer Vertrags-Präambel formulieren.

Der Dreiecks-Check

Woher weiß man während des Projekts, ob das umgedrehte Dreieck überhaupt noch gleichschenklig ist oder schon eine Tendenz zum stumpfen Winkel bekommt? Wenn der Scope nicht genau definiert ist, fehlen oft auch quantifizierbare Qualitätsmerkmale. Besonders für den ersten und letzten Schritt im oben beschriebenen Ablauf kann das fatal sein. Nicht messbare Ziele / nicht messbarer Nutzen dürften vor Gericht sehr schwer einzuklagen sein. In einem Foliensatz über agile Verträge habe ich die Überschrift “Richter sind keine Scrum-Master” gelesen. Wie wahr. Die Rechtsprechung kann sich nur auf den Wortlaut eines Vertrages beziehen. Man kann nicht erwarten, dass man im Zweifelsfall einem Richter vor der Urteilssprechung noch schnell die agile “Definition of Done” vermitteln kann. Darin sieht Kane Mar, einer der ersten 30 Scrum Trainer weltweit, ein großes Problem [3]:

Eine DoD bricht Festpreis-Verträge. Der Versuch, einen Vertrag mit Scrum zu einem Festpreis zu erfüllen, wird zu einem iterativen Todesmarsch gegen das Konzept.

Aus seiner Sicht dient Scrum dazu, Qualität zu liefern, was nur möglich ist, wenn die Seiten des magischen Dreiecks zur Erfüllung der Definition of Done flexibel sind. Wenn Zeit, Geld oder andere Anforderungen verhindern, dass die DoD in allen Punkten abgehakt werden kann, ist seiner Einschätzung nach die Qualität generell gefährdet.

Die Meinungen, ob der agile Festpreis wirklich funktioniert, driften stark auseinander. Was sicherlich funktioniert, ist, kleinere Einheiten (z.B. auf Sprintebene) fest zu bepreisen, bei großen Ausschreibungsprojekten dürfte der agile Festpreis aber kaum durchsetzbar sein. Außerdem birgt die Kooperation von Dienstleister und Kunde ein gewisses Definitions-Risiko in sich. So wurde 2017 bei einem Rechtsstreit vor dem Landgericht München festgestellt, dass ein Dienstvertrag und kein Werksvertrag vorlag, weil der Auftraggeber den Product Owner stellte. Die Kanzlei JunIT für IT- und Wirtschaftsrecht schreibt dazu auf ihrer Website [4]:

Ein Scrum-Vertrag als Werkvertrag auszulegen ist schwierig, aber nicht ganz unmöglich. Es kommt darauf an, wie die Parteien das Vertragsverhältnis ausgestalten. Für einen Software-Entwickler macht die Unterscheidung jedoch immense Unterschiede in der Kalkulation und vor allem bei der Gewährleistung.

Merke also: Bei allem gegenseitigen Wohlwollen hat man im Streitfall schlechte Karten, wenn man die Zusammenarbeit und die zu erbringende Leistung nicht möglichst konkret vertraglich fixiert hat. Denn die Gerichte urteilen auf Grundlage von Fakten, Fakten, Fakten.

Woher kommen Fakten?

Fakten muss man belegen können. Deshalb lohnt es sich, Anforderungen von den Epics bis zu den User Stories zu dokumentieren. Wenn diese sehr variabel sein dürfen, kann eine Änderungshistorie sehr nützlich sein. Bei größeren Projekten werden die Backlogs vielleicht auch in parallel laufenden Sprints von mehreren Teams abgearbeitet. Um dann den Überblick zu behalten, wie es mit den Faktoren Kosten und Zeit aussieht, braucht man die Möglichkeit, jederzeit einen aktuellen Plan/Ist-Kosten-Vergleich zu ziehen. Nur so kann man mit dem Vertragspartner gemeinsam kontrollieren, ob die Budgetplanung realistisch war. Je transparenter der Status Quo der Entwicklung ist, desto weniger kommt es vielleicht auch zu Differenzen. Wir empfehlen Ihnen einen Blick in objectiF RPM zu werfen. Mit unserer Software können Sie sämtliche Zwischenberichte einfach per Mausklick generieren und dem Auftraggeber per Web-Client den gewünschten Zugriff auf die Projektdaten gewähren. Holen Sie sich dafür Ihr kostenloses 30-Tage Trial hier.

Quellen:

[1] Opelt, A., Gloger, B., Pfarl, W., Mittermayr, R. : Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge, Carl Hanser Verlag GmbH & Co. KG, 3. Auflage, 2017
[2] https://www.informatik-#_ftnref4aktuell.de/management-und-recht/projektmanagement/der-agile-festpreis-gemeinsamer-nenner-fuer-dienstleister-und-unternehmen.html
[3] https://www.scrumexpert.com/knowledge/the-implications-of-having-a-definition-of-done-on-fixed-priced-contracts/
[4] https://www.junit.de/21-portfolio/open-source-recht/open-source-im-unternehmen/577-agile-software-entwicklung-mit-scrum-als-werk-oder-dienstvertrag