Ein mittelständischer Maschinenbauer möchte ein Kundenportal für Ersatzteilbestellungen. Der Einkauf verlangt einen Festpreis, das Pflichtenheft soll bis zum Vertragsschluss fertig sein. Der Dienstleister schlägt dagegen Scrum vor: zweiwöchige Sprints, ein Product Owner auf Kundenseite, Prioritäten, die sich mit jedem Feedback verschieben dürfen. Beide Seiten haben gute Gründe. Nur passen sie auf den ersten Blick nicht in denselben Vertrag.

Genau an dieser Stelle setzen agile Verträge an. Gemeint sind keine besonderen Rechtsformen, sondern Vertragsgestaltungen, die mit einem beweglichen Leistungsumfang umgehen können, ohne dass Budget, Verantwortung und Haftung im Ungefähren bleiben. Wer sie versteht, verhandelt realistischer und streitet am Ende seltener.

Warum klassische Festpreisverträge bei Software oft scheitern

Ein klassischer Festpreisvertrag beruht auf einer Annahme: Der Auftraggeber weiß zu Beginn, was er braucht, und kann es so genau beschreiben, dass der Dienstleister einen Preis kalkulieren kann. Bei einer Lagerhalle funktioniert das meist. Bei Software selten, denn viele Anforderungen zeigen sich erst, wenn Nutzer eine erste Version in der Hand haben.

Die Folgen sind bekannt. Der Dienstleister schlägt einen Risikoaufschlag auf den Preis, weil er die Unsicherheit tragen soll. Jede Abweichung vom Pflichtenheft wird zum Änderungsantrag, der verhandelt und nachkalkuliert werden muss. Am Ende wird oft geliefert, was im Vertrag steht, nicht das, was der Fachbereich inzwischen braucht. Und weil beide Seiten ihre Position absichern, wächst der Aufwand für Dokumentation und Abstimmung.

Das agile Manifest von 2001 hat diesen Konflikt in einen seiner vier Werte gegossen: Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlung. Das heißt nicht, dass Verträge unwichtig wären. Es heißt, dass ein Vertrag die Zusammenarbeit ermöglichen soll, statt sie durch starre Festlegungen zu ersetzen.

Das eiserne Dreieck umgedreht

Projektverantwortliche kennen das magische oder eiserne Dreieck aus Umfang, Zeit und Kosten. Im klassischen Vorgehen wird der Umfang festgelegt, Zeit und Kosten werden daraus geschätzt. Agile Vorgehensmodelle drehen das Dreieck um: Budget und Zeitrahmen stehen fest, der Umfang ergibt sich aus dem, was das Team in dieser Zeit in sinnvoller Reihenfolge liefert.

Damit das nicht zur Ausrede für halbfertige Ergebnisse wird, braucht es drei Dinge:

• Ein priorisiertes Backlog, also eine geordnete Liste aller gewünschten Funktionen. Was oben steht, wird zuerst gebaut. Fällt das Budget knapp aus, fehlen die unwichtigsten Punkte, nicht die zentralen.
• Eine gemeinsame Definition of Done, die festlegt, wann eine Funktion als fertig gilt: getestet, dokumentiert, auf einer Testumgebung lauffähig. Qualität ist damit keine Stellschraube, an der gespart wird.
• Regelmäßige Reviews, in denen der Auftraggeber funktionierende Software sieht und die Prioritäten anpasst.

Wie das im Scrum-Alltag aussieht, beschreibt der Beitrag Scrum entmystifiziert: Was das Framework leistet und was nicht. Für den Vertrag ist entscheidend: Diese Mechanismen müssen dort beschrieben sein, sonst bleiben sie eine unverbindliche Absichtserklärung.

Die wichtigsten Vertragsmodelle im Überblick

In der Praxis haben sich einige Grundmodelle durchgesetzt. Sie lassen sich kombinieren, und die Namen sind nicht einheitlich. Entscheidend ist, wie Risiko und Steuerung zwischen den Parteien verteilt werden.

Time & Materials: maximale Beweglichkeit

Bei Time & Materials, kurz T&M, bezahlt der Auftraggeber die geleisteten Stunden oder Tage zu vereinbarten Sätzen. Der Umfang kann sich jederzeit ändern, ohne dass nachverhandelt werden muss. Das Kostenrisiko trägt allerdings fast vollständig der Kunde. T&M eignet sich für eingespielte Partnerschaften und für Projekte, deren Ziel sich erst in der Arbeit klärt. Ohne regelmäßige Budgetberichte und klare Prioritäten kann es teuer werden.

Capped T&M: Aufwand mit Deckel

Die gedeckelte Variante ergänzt T&M um eine Obergrenze, etwa je Sprint, je Release oder für das Gesamtprojekt. Ist der Deckel erreicht, endet die Leistungspflicht oder es wird neu verhandelt. Für viele Auftraggeber ist das der pragmatische Einstieg, weil der Einkauf eine feste Zahl bekommt. Der Dienstleister sollte darauf achten, dass der Deckel nicht stillschweigend zur Zusage eines bestimmten Funktionsumfangs wird.

Agiler Festpreis: fester Rahmen, beweglicher Inhalt

Der agile Festpreis, im deutschsprachigen Raum vor allem durch das gleichnamige Fachbuch von Andreas Opelt und Koautoren bekannt geworden, verbindet beide Welten. Zu Beginn wird der Gesamtumfang nur grob beschrieben, etwa als Liste von Epics, also großen Funktionsblöcken. Ein exemplarischer Teil wird gemeinsam im Detail geschätzt. Daraus ergibt sich ein Preisrahmen. Im Projekt dürfen Anforderungen gegen gleich große ausgetauscht werden, solange der Gesamtumfang gleich bleibt. Häufig gehören eine gemeinsame Prüfphase am Anfang und Regeln für Mehr- oder Minderaufwand dazu.

Target Cost: Gewinn und Verlust teilen

Beim Zielkostenmodell vereinbaren die Parteien einen Zielpreis. Wird er unterschritten, teilen sie die Einsparung nach einem festen Schlüssel. Wird er überschritten, tragen beide Seiten die Mehrkosten anteilig, etwa indem der Stundensatz des Dienstleisters für den Mehraufwand sinkt. Eine Variante ist das Fixed-Profit-Modell: Der Gewinnanteil des Dienstleisters ist in absoluter Höhe fest, Mehraufwand wird nur noch zu Selbstkosten berechnet. Beide Modelle setzen voraus, dass Kalkulationen offengelegt werden. Das verlangt Vertrauen, das in manchen Branchen erst wachsen muss.

Sequenzielle Verträge: Vertrauen in Etappen

Statt eines großen Auftrags werden mehrere kleine nacheinander vergeben, etwa ein Auftrag für eine Konzeptphase und dann je einer für jedes Release. Nach jeder Etappe können beide Seiten die Zusammenarbeit fortsetzen, anpassen oder beenden. Das begrenzt das Risiko auf die laufende Phase. Der Nachteil ist der Verwaltungsaufwand, wenn jede Etappe einen neuen Einkaufsprozess durchläuft. Ein Rahmenvertrag mit Einzelabrufen löst das oft eleganter.

Ausstiegsklauseln und „Money for Nothing, Change for Free“

Unter diesem Namen hat Jeff Sutherland, einer der Begründer von Scrum, zwei Klauseln bekannt gemacht, die sich mit fast jedem Modell kombinieren lassen.

Change for Free bedeutet: Der Auftraggeber darf noch nicht begonnene Anforderungen jederzeit gegen andere mit gleichem geschätztem Aufwand tauschen, ohne Mehrkosten. Voraussetzung ist, dass er aktiv mitarbeitet, also Reviews besucht und Prioritäten pflegt.

Money for Nothing regelt den vorzeitigen Ausstieg. Stellt der Kunde nach einigen Sprints fest, dass die wichtigsten Funktionen vorhanden sind und der Rest den Aufwand nicht lohnt, kann er das Projekt beenden. Er zahlt dann einen vorher vereinbarten Anteil des verbleibenden Budgets als Ausgleich für den Dienstleister, der seine Kapazität geplant hatte.

Angenommen, das Kundenportal ist mit 20 Sprints kalkuliert. Nach 14 Sprints sind Bestellung, Teilesuche und Rechnungsansicht fertig, die übrigen Wünsche sind eher Komfort. Mit einer solchen Klausel kann der Maschinenbauer aufhören und spart einen Großteil der restlichen Kosten, der Dienstleister erhält eine faire Entschädigung. Wie hoch dieser Anteil ist, wird individuell verhandelt.

Rechtliche Einordnung: worauf Sie im deutschen Recht achten sollten

Agile Verträge sind genauso verbindlich wie alle anderen. Schwierig wird es bei der Frage, welcher Vertragstyp vorliegt, denn davon hängen Haftung und Gewährleistung ab. Die folgenden Hinweise sind allgemeine Informationen und ersetzen keine Rechtsberatung.

• Werkvertrag oder Dienstvertrag: Beim Werkvertrag nach §§ 631 ff. BGB schuldet der Dienstleister einen Erfolg, etwa eine funktionierende Software, und es gibt eine Abnahme. Beim Dienstvertrag nach §§ 611 ff. BGB schuldet er die Tätigkeit selbst. Reine T&M-Verträge werden häufig als Dienstvertrag gestaltet, agile Festpreise eher als Werkvertrag mit Teilabnahmen. Seit 2022 gibt es zudem eigene Regeln für Verträge über digitale Produkte mit Verbrauchern, die im B2B-Geschäft aber meist keine Rolle spielen.
• Abnahme: Wer werkvertraglich arbeitet, sollte festlegen, ob nach jedem Sprint oder Release abgenommen wird und was die Definition of Done dafür bedeutet. Sonst bleibt unklar, wann Gewährleistungsfristen beginnen.
• Mitwirkungspflichten: Agile Projekte funktionieren nur, wenn der Auftraggeber mitarbeitet. Der Vertrag sollte beschreiben, welche Rolle er besetzt, etwa den Product Owner, und was passiert, wenn Entscheidungen ausbleiben.
• Weisungen und Arbeitnehmerüberlassung: Arbeiten externe Entwickler eng im Team des Kunden und erhalten dort Arbeitsanweisungen, kann das als verdeckte Arbeitnehmerüberlassung oder Scheinselbstständigkeit gewertet werden. Steuerung sollte deshalb über das Backlog und die vereinbarten Rollen laufen, nicht über Anweisungen an einzelne Personen.

Gerade die letzten beiden Punkte werden oft unterschätzt. Ein sauber beschriebenes Rollenmodell schützt beide Seiten.

Was in einen agilen Vertrag gehört

Unabhängig vom Modell lohnt sich eine Checkliste. Ein tragfähiger agiler Vertrag beschreibt mindestens:

1. das Projektziel und die grobe Produktvision, damit klar ist, woran Prioritäten gemessen werden,
2. das Vorgehensmodell mit Sprintlänge, Rollen und Terminen für Review und Planung,
3. die Definition of Done und das Verfahren für Abnahmen,
4. das Budget, die Abrechnungslogik und gegebenenfalls Obergrenzen,
5. Regeln für Änderungen am Umfang und für den Tausch von Anforderungen,
6. Ausstiegs- und Kündigungsrechte samt Ausgleichszahlungen,
7. einen Eskalationsweg, falls sich die Parteien bei Prioritäten oder Qualität nicht einigen.

Für die Budgetsteuerung helfen Kennzahlen wie Velocity oder Burn-up-Charts. Welche Metriken aussagekräftig sind und welche eher in die Irre führen, zeigt der Beitrag zu Agile Metrics in der Projektsteuerung.

Was das für Auftraggeber und Dienstleister bedeutet

Agile Verträge lösen keine Vertrauensprobleme, sie machen sie nur früher sichtbar. Wer dem Partner grundsätzlich misstraut, wird mit T&M unglücklich und mit einem agilen Festpreis nicht glücklicher. Für die meisten Projekte im Mittelstand ist ein Mittelweg realistisch: ein agiler Festpreis oder ein gedeckeltes Aufwandsmodell, kombiniert mit einer Ausstiegsklausel und klar beschriebenen Mitwirkungspflichten.

Überschätzt wird oft die Bedeutung des Vertragsmodells selbst. Wichtiger ist, dass beide Seiten die agile Arbeitsweise tatsächlich leben: Der Kunde nimmt an Reviews teil und priorisiert, der Dienstleister liefert regelmäßig funktionierende Zwischenstände und berichtet offen über das Budget. Dafür braucht es eine passende Haltung, wie sie der Beitrag Agiles Mindset in der Softwareentwicklung beschreibt. Ein guter Vertrag schreibt diese Praxis fest und gibt beiden Seiten einen geordneten Weg, wenn sie nicht funktioniert.

Wer agile Vorgehensmodelle im eigenen Unternehmen einführen oder Einkauf und Fachbereich darauf vorbereiten möchte, findet auf der Seite zu Beratung und Seminaren für agile Methoden einen Überblick über unsere Angebote.

Häufige Fragen zu agilen Verträgen

Sind agile Verträge rechtlich bindend?

Ja. Es gibt im deutschen Recht keinen eigenen Vertragstyp „agiler Vertrag“, die Vereinbarungen werden als Werk- oder Dienstvertrag oder als Mischform eingeordnet und sind entsprechend verbindlich. Je klarer Rollen, Abnahmen und Vergütung beschrieben sind, desto geringer ist das Risiko, dass ein Gericht im Streitfall einen anderen Vertragstyp annimmt als die Parteien beabsichtigt hatten.

Wie überzeugt man einen Einkauf, der auf einem Festpreis besteht?

Meist hilft es, die Sorge hinter der Forderung ernst zu nehmen: Der Einkauf will eine verlässliche Budgetzahl. Die liefern auch ein agiler Festpreis oder ein gedeckeltes Aufwandsmodell. Der Unterschied liegt darin, dass der Umfang nicht vorab bis ins Detail festgeschrieben wird. Ein kurzer, separat beauftragter Einstieg, etwa zwei Sprints, macht die Arbeitsweise für alle Beteiligten greifbar.

Welches Modell eignet sich für den Einstieg in die Zusammenarbeit?

Für neue Partnerschaften sind sequenzielle Verträge oder ein kleiner Erstauftrag mit Kostendeckel sinnvoll. Beide Seiten lernen sich kennen, ohne sich langfristig zu binden. Wenn die Zusammenarbeit funktioniert, kann ein Rahmenvertrag mit mehr Beweglichkeit folgen.