Agile Verträge mit Dienstleistern: Zusammenarbeit statt Lastenheft

Agile Verträge mit Dienstleistern regeln ein Produktziel, einen Rhythmus für Lieferung und Abnahme sowie eine Obergrenze für Aufwand und lassen den Umfang im Detail offen. Sie lösen das Lastenheft ab, wenn sich Anforderungen im Projekt erst klären. Welches Modell passt, entscheiden drei Kriterien: wie klar der Umfang ist, wie stark sich Anforderungen ändern und wie eng Auftraggeber und Dienstleister zusammenarbeiten.

Dieser Beitrag vergleicht die gängigen Vertragsmodelle, gibt Ihnen eine Prüfliste für die Auswahl an die Hand und beschreibt, wie Sie die Zusammenarbeit im laufenden Projekt steuern. Die Ausgestaltung eines Vertrags liegt bei Ihrer Rechtsabteilung und Ihren Anwälten. Dieser Beitrag gibt einen Überblick und ersetzt keine Rechtsberatung.

Warum scheitern Lastenhefte in Softwareprojekten?

Lastenhefte scheitern, weil sie vom Wissen des Projektbeginns ausgehen und dieses Wissen im Projekt wächst. Die DIN 69901-5 beschreibt das Lastenheft als Gesamtheit der Forderungen des Auftraggebers und das Pflichtenheft als Antwort des Auftragnehmers darauf. Dieses Modell funktioniert, wo Anforderungen stabil sind, etwa bei einer Anlage mit festen Spezifikationen. Bei Software kommen Erkenntnisse aus dem Einsatz hinzu, die niemand vorher kannte.

Der Software-Ökonom Barry Boehm hat 1981 gezeigt, dass Aufwandsschätzungen in frühen Projektphasen um einen Faktor von etwa vier nach oben oder unten danebenliegen können, und dass die Streuung mit dem Fortschritt sinkt. Eine Untersuchung von Flyvbjerg und Budzier mit 1.471 IT-Projekten zeigte eine durchschnittliche Kostenüberschreitung von 27 Prozent, und bei jedem sechsten Projekt lag die Kostenüberschreitung im Durchschnitt bei 200 Prozent. Ein Festpreis auf Basis einer frühen Schätzung bildet diese Unsicherheit nicht ab. Er verlagert sie. Der Dienstleister kalkuliert Puffer ein, oder er verteidigt den Umfang des Lastenhefts Zeile für Zeile, und der Auftraggeber bekommt am Ende das, was im Papier stand, auch wenn es nicht mehr dem entspricht, was er braucht.

Das Agile Manifest von 2001 hat diesen Konflikt in einem Satz festgehalten: Zusammenarbeit mit dem Kunden steht über Vertragsverhandlung. Daraus folgt die Aufgabe, Verträge zu schreiben, die Zusammenarbeit zulassen und ihr einen verbindlichen Rahmen geben.

Welche Vertragsmodelle gibt es für agile Zusammenarbeit?

Für agile Zusammenarbeit sind vier Vertragsmodelle üblich: Festpreis mit festem Umfang, Abrechnung nach Aufwand, Team-Vertrag und Festpreis mit variablem Umfang. Als Kombination kommt das Phasenmodell hinzu. Die Modelle unterscheiden sich darin, bei wem das Risiko für Umfang und Aufwand liegt und wie viel Änderung sie vertragen.

Der Festpreis mit variablem Umfang ist das Modell, das das Muster „Money for Nothing, Change for Free“ von Jeff Sutherland beschreibt. Der Preis steht fest, der Auftraggeber darf Anforderungen im Backlog austauschen, solange das Gesamtvolumen gleich bleibt, und er kann die Zusammenarbeit beenden, sobald der wesentliche Wert geliefert ist, wobei der Dienstleister nach Vereinbarung einen Anteil des Restpreises erhält. Das Muster setzt voraus, dass der Auftraggeber Scrum tatsächlich mitlebt, etwa mit einem Product Owner, der Entscheidungen trifft. Der Team-Vertrag eignet sich für Produkte, die über Jahre wachsen, und rechnet Kapazität je Zeitraum ab und misst die Zusammenarbeit an Zielen.

Das Phasenmodell verbindet die Modelle. Eine erste kurze Phase nach Aufwand oder zu einem begrenzten Festpreis klärt Anforderungen und Architektur, danach entscheiden beide Seiten, ob und in welchem Modell die Lieferung weiterläuft. Es passt, wenn Ziel und Lösungsweg für einen agilen Rahmen noch nicht klar genug sind. Wie sich Festpreis und flexibler Umfang im Projekt verbinden lassen, beschreibt der Beitrag zu agilen Festpreisprojekten.

Wie wählen Sie das passende Vertragsmodell?

Das passende Modell ergibt sich aus fünf Fragen, die Sie vor der Ausschreibung beantworten. Jede Frage mit Ja verschiebt die Wahl in Richtung eines agilen Modells.

1. Ändern sich Anforderungen voraussichtlich im Projekt, weil Nutzer erst im Einsatz zeigen, was sie brauchen?
2. Lässt sich das Ziel in einem Satz beschreiben, die Lösung aber nicht vollständig im Voraus?
3. Kann Ihr Unternehmen einen Product Owner mit Entscheidungsbefugnis benennen, der pro Woche Zeit für das Team hat?
4. Ist Ihnen ein Ergebnis in Etappen mit Nutzen nach wenigen Wochen mehr wert als ein vollständiges Ergebnis am Ende?
5. Arbeiten Sie mit dem Dienstleister bereits zusammen oder können Sie in einer Pilotphase Vertrauen aufbauen?

Mit vier oder fünf Ja passt ein Team-Vertrag oder ein Festpreis mit variablem Umfang. Mit zwei oder drei Ja empfiehlt sich das Phasenmodell, weil eine erste Phase die offenen Punkte klärt, bevor beide Seiten sich binden. Mit null oder einem Ja bleibt der klassische Festpreis angemessen, weil Umfang und Anforderungen stabil sind.

Was gehört in einen agilen Vertrag?

In einen agilen Vertrag gehören sieben Bestandteile, die Zusammenarbeit regeln, ohne den Umfang im Detail festzulegen. Wie sie rechtlich auszuformulieren sind, klären Ihre Fachleute.

1. Produktziel und Wertmaßstab: Das Ziel des Vorhabens in wenigen Sätzen und die Kennzahl, an der der Nutzen gemessen wird. Das Produktziel nach dem Scrum Guide von 2020 erfüllt diese Rolle.
2. Rhythmus: Lieferung in festen Zyklen, mit einer Vorführung am Ende jedes Zyklus. Die Sprint Review dient als Punkt, an dem der Auftraggeber prüft und entscheidet.
3. Definition of Done: Eine schriftliche Beschreibung, wann ein Ergebnis als fertig gilt, damit Abnahme nicht jedes Mal neu verhandelt wird.
4. Rollen: Der Auftraggeber stellt den Product Owner, der Dienstleister das Team. Beide Seiten benennen eine Ansprechperson für Eskalationen.
5. Obergrenze und Ausstiegspunkte: Eine Summe, die ohne neue Entscheidung nicht überschritten wird, und die Möglichkeit, nach jedem Zyklus zu beenden.
6. Transparenz: Zugang zum Backlog, zu Arbeitsständen und zu Kennzahlen für beide Seiten.
7. Umgang mit Änderungen: Ein einfacher Weg, Anforderungen zu tauschen, und eine Regel, wie sich Umfang und Aufwand dabei verhalten.

Wie steuern Sie einen Dienstleister im agilen Projekt?

Sie steuern den Dienstleister über Ergebnisse in kurzen Zyklen. Das Instrument ist die Sprint Review: Der Dienstleister zeigt lauffähige Ergebnisse, der Product Owner des Auftraggebers entscheidet über Abnahme und Reihenfolge. Termine lassen sich mit Wahrscheinlichkeiten angeben, wie der Beitrag zu Lieferprognosen mit Monte-Carlo-Simulation zeigt, und für Vorstände eignet sich eine Planung in Meilensteinen, die der Beitrag zur Meilensteinplanung in agilen Programmen beschreibt.

Zwei Muster bringen Verträge in Schieflage. Das erste ist ein Product Owner ohne Zeit oder Befugnis. Der Dienstleister wartet auf Entscheidungen, und die Wartezeit geht in Aufwand oder Termin ein. Das zweite ist ein Backlog ohne Priorität, in dem alles wichtig ist. Hier hilft die Frage, welche Verzögerung welche Kosten verursacht, wie sie der Beitrag zu Cost of Delay beschreibt.

Gemeinsam mit Niehues Consulting zu belastbaren Dienstleisterbeziehungen

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen und in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management und Organisationsdesign übernimmt die Beratung Aufgaben als Delivery Manager, Projektmanager oder Product Owner und steuert damit die Zusammenarbeit mit Dienstleistern aus der Sicht des Auftraggebers.

Das Vorgehen folgt dem Niehues Delivery Model mit seinen drei Phasen. Für Verträge mit Dienstleistern zählen drei Prüffragen: Wer entscheidet, wer liefert, wer nutzt? Welche Rollen, Entscheidungswege und Schnittstellen braucht der Betrieb? Welche Kennzahl zeigt nach 90 Tagen, dass die Lösung ankommt? Umfang und Konditionen eines Vorhabens werden in der kostenfreien Erstberatung besprochen, die Sie über den Kontakt in 30 Minuten vereinbaren.