Agiler Projektvertrag: Scrum und Kanban rechtssicher gestalten

Agile Methoden haben sich in der Softwareentwicklung durchgesetzt. Die Verträge dahinter sind meist nicht mitgewachsen: Was in der Praxis als agiler Projektvertrag unterschrieben wird, ist häufig ein klassischer Werkvertrag mit einem Scrum-Kapitel im Anhang – oder ein reiner Dienstvertrag, bei dem der Auftraggeber am Ende zahlt, ohne ein funktionierendes Ergebnis verlangen zu können.

Beides geht in der Regel schief, und zwar auf vorhersehbare Weise. Ein agiler Vertrag muss etwas leisten, was die Vertragstypen des BGB nicht vorsehen: Er muss den Leistungsumfang offenhalten und gleichzeitig verbindlich regeln, wer welches Risiko trägt, wann bezahlt wird und woran sich Erfolg messen lässt.

Jetzt Kontakt aufnehmen!

Warum der klassische Werkvertrag bei agilen Projekten nicht passt

Das Werkvertragsrecht beruht auf einer klaren Risikoverteilung: Der Auftragnehmer schuldet einen bestimmten Erfolg und trägt allein das Fertigstellungsrisiko. Diese Verteilung passt zum Wasserfallmodell mit vollständigem Lasten- und Pflichtenheft – sie passt nicht zu agilem Vorgehen.

Bei agilen Projekten ist der Auftragnehmer auf die fortlaufende Mitwirkung des Auftraggebers angewiesen. Der Product Owner priorisiert, entscheidet und gibt frei. Fehlt er, steht das Projekt. Ein Auftragnehmer, der das volle Fertigstellungsrisiko trägt, obwohl er den Leistungsinhalt nicht allein bestimmen kann, wird das über Risikoaufschläge oder Vorbehalte kompensieren – oder er scheitert daran.

Hinzu kommt ein grundlegender Unterschied in den Dokumenten: Product Backlog und Sprint Backlog sind nicht mit einem Lasten- oder Pflichtenheft vergleichbar. Sie enthalten bewusst unverbindliche, jederzeit änderbare und neu priorisierbare Anforderungen. Wer ein Backlog zur vertraglichen Leistungsbeschreibung erklärt, macht ein bewegliches Arbeitsmittel zum starren Vertragsgegenstand – und erzeugt genau die Konflikte, die die agile Methode vermeiden soll.

Der reine Dienstvertrag ist allerdings ebenso wenig die Lösung. Er verlagert das gesamte Ergebnisrisiko auf den Auftraggeber, der dafür in der Regel nicht über das nötige technische Know-how verfügt.

Vertragsmodelle für agile Projekte im Vergleich

Es gibt nicht den einen agilen Projektvertrag. Welches Modell trägt, hängt davon ab, welche Parameter Sie fixieren müssen und welche offenbleiben dürfen:

• Dienstvertrag auf Aufwandsbasis (Time & Material) – maximale Flexibilität, aber ohne Erfolgsbindung. Nur tragfähig mit Budgetdeckel, Reporting- und Steuerungsrechten sowie klaren Abbruchmöglichkeiten.
• Werkvertrag je Sprint oder Inkrement – jedes Inkrement ist ein eigenes Werk mit eigener Abnahme. Präzise, aber administrativ aufwendig und nur bei hinreichend abgegrenzten Inkrementen sinnvoll.
• Agiler Festpreis mit Zielpreis und Risikoteilung – Budget und Termin sind fixiert, der Funktionsumfang bleibt variabel. Über- und Unterschreitungen werden nach einem vereinbarten Schlüssel geteilt. Das derzeit ausgewogenste Modell für größere Vorhaben.
• Rahmenvertrag mit Einzelabrufen – ein Rahmen regelt Rollen, Vergütungssätze, Rechte und Haftung; jeder Sprint oder Release wird einzeln abgerufen. Besonders geeignet für langfristige Zusammenarbeit und für öffentliche Auftraggeber.
• Hybride Gestaltung – ein werkvertraglich fixierter Kern (Infrastruktur, Schnittstellen, Migration) und ein agil entwickelter Funktionsbereich. In der Praxis häufig die realistischste Variante.

Wir wählen mit Ihnen das Modell, das zu Ihrem Vorhaben und Ihrer Verhandlungsposition passt – und formulieren es so, dass es einer AGB-Kontrolle standhält.

Die Regelungen, an denen agile Verträge scheitern

• Produktvision und Rahmenanforderungen – ein Minimum an verbindlicher Zielbeschreibung, ohne das Backlog einzufrieren
• Rollen und Besetzung – Product Owner, Scrum Master, Teamzusammensetzung, Schlüsselpersonenklauseln, Vertretungsregeln
• Mitwirkungspflichten als echte Vertragspflichten – Verfügbarkeit des Product Owners, Entscheidungsfristen, Testressourcen. Bleiben sie unverbindlich, greifen die Rechte aus §§ 642, 643 BGB ins Leere.
• Definition of Done – der wichtigste Hebel überhaupt: sie ersetzt in agilen Projekten faktisch die Abnahmekriterien
• Abnahme – Sprint-Freigabe, Teilabnahme von Inkrementen oder Gesamtabnahme am Ende? Davon hängen Gewährleistungsfristen, Gefahrübergang und Vergütungsfälligkeit ab.
• Vergütung und Budgetsteuerung – Sprint-Pauschalen, Zielpreis, Deckelung, Eskalation bei Budgetausschöpfung
• Gewährleistung mit Augenmaß – nicht umgesetzte oder fehlerhafte Anforderungen wandern zurück ins Backlog und werden in einem späteren Sprint bearbeitet. Nicht jeder Fehler ist ein Mangel. Echte Programmier- und Entwicklungsfehler, die sich nach Abschluss der Entwicklung auf die Funktion auswirken, müssen dagegen von den Gewährleistungsrechten erfasst sein. Diese Grenze sauber zu ziehen, ist Kernaufgabe der Vertragsgestaltung.
• Nutzungs- und Verwertungsrechte – laufende Rechteübertragung an jedem Inkrement, nicht erst bei Projektende. Sonst stehen Sie bei einem Abbruch mit Code ohne Rechte da.
• Dokumentation – in agilen Projekten notorisch vernachlässigt und im Streitfall entscheidend
• Kündigung und Exit zum Sprintende – geordnete Beendigung mit Übergabe, Dokumentation und Fortführungsmöglichkeit durch Dritte
• Abgrenzung zur Arbeitnehmerüberlassung – gemischte Teams aus eigenen und externen Kräften unter Weisung eines Product Owners bergen Risiken nach AÜG und im Bereich der Scheinselbständigkeit. Diese Abgrenzung gehört in den Vertrag und in die Projektorganisation.
• Datenschutz – Auftragsverarbeitung, Testdaten aus dem Produktivsystem, Zugriffsrechte externer Entwickler

Vertragsmodelle für agile Projekte im Vergleich

Es gibt nicht den einen agilen Projektvertrag. Welches Modell trägt, hängt davon ab, welche Parameter Sie fixieren müssen und welche offenbleiben dürfen:

• Dienstvertrag auf Aufwandsbasis (Time & Material) – maximale Flexibilität, aber ohne Erfolgsbindung. Nur tragfähig mit Budgetdeckel, Reporting- und Steuerungsrechten sowie klaren Abbruchmöglichkeiten.
• Werkvertrag je Sprint oder Inkrement – jedes Inkrement ist ein eigenes Werk mit eigener Abnahme. Präzise, aber administrativ aufwendig und nur bei hinreichend abgegrenzten Inkrementen sinnvoll.
• Agiler Festpreis mit Zielpreis und Risikoteilung – Budget und Termin sind fixiert, der Funktionsumfang bleibt variabel. Über- und Unterschreitungen werden nach einem vereinbarten Schlüssel geteilt. Das derzeit ausgewogenste Modell für größere Vorhaben.
• Rahmenvertrag mit Einzelabrufen – ein Rahmen regelt Rollen, Vergütungssätze, Rechte und Haftung; jeder Sprint oder Release wird einzeln abgerufen. Besonders geeignet für langfristige Zusammenarbeit und für öffentliche Auftraggeber.
• Hybride Gestaltung – ein werkvertraglich fixierter Kern (Infrastruktur, Schnittstellen, Migration) und ein agil entwickelter Funktionsbereich. In der Praxis häufig die realistischste Variante.

Wir wählen mit Ihnen das Modell, das zu Ihrem Vorhaben und Ihrer Verhandlungsposition passt – und formulieren es so, dass es einer AGB-Kontrolle standhält.

Die Regelungen, an denen agile Verträge scheitern

• Produktvision und Rahmenanforderungen – ein Minimum an verbindlicher Zielbeschreibung, ohne das Backlog einzufrieren
• Rollen und Besetzung – Product Owner, Scrum Master, Teamzusammensetzung, Schlüsselpersonenklauseln, Vertretungsregeln
• Mitwirkungspflichten als echte Vertragspflichten – Verfügbarkeit des Product Owners, Entscheidungsfristen, Testressourcen. Bleiben sie unverbindlich, greifen die Rechte aus §§ 642, 643 BGB ins Leere.
• Definition of Done – der wichtigste Hebel überhaupt: sie ersetzt in agilen Projekten faktisch die Abnahmekriterien
• Abnahme – Sprint-Freigabe, Teilabnahme von Inkrementen oder Gesamtabnahme am Ende? Davon hängen Gewährleistungsfristen, Gefahrübergang und Vergütungsfälligkeit ab.
• Vergütung und Budgetsteuerung – Sprint-Pauschalen, Zielpreis, Deckelung, Eskalation bei Budgetausschöpfung
• Gewährleistung mit Augenmaß – nicht umgesetzte oder fehlerhafte Anforderungen wandern zurück ins Backlog und werden in einem späteren Sprint bearbeitet. Nicht jeder Fehler ist ein Mangel. Echte Programmier- und Entwicklungsfehler, die sich nach Abschluss der Entwicklung auf die Funktion auswirken, müssen dagegen von den Gewährleistungsrechten erfasst sein. Diese Grenze sauber zu ziehen, ist Kernaufgabe der Vertragsgestaltung. Wie sich Fehler, noch nicht umgesetzte Anforderungen und echte Mängel voneinander abgrenzen lassen, ist insbesondere für das Mängelmanagement in IT-Projekten entscheidend.
• Nutzungs- und Verwertungsrechte – laufende Rechteübertragung an jedem Inkrement, nicht erst bei Projektende. Sonst stehen Sie bei einem Abbruch mit Code ohne Rechte da.
• Dokumentation – in agilen Projekten notorisch vernachlässigt und im Streitfall entscheidend
• Kündigung und Exit zum Sprintende – geordnete Beendigung mit Übergabe, Dokumentation und Fortführungsmöglichkeit durch Dritte
• Abgrenzung zur Arbeitnehmerüberlassung – gemischte Teams aus eigenen und externen Kräften unter Weisung eines Product Owners bergen Risiken nach AÜG und im Bereich der Scheinselbständigkeit. Diese Abgrenzung gehört in den Vertrag und in die Projektorganisation.
• Datenschutz – Auftragsverarbeitung, Testdaten aus dem Produktivsystem, Zugriffsrechte externer Entwickler

Wenn das agile Projekt abgebrochen werden muss

Ein möglicher Ausgang eines agilen Projekts ist der Abbruch. Die Gründe sind vielfältig: mangelnde Kooperationsfähigkeit im Team, geänderte Marktbedingungen oder die Erkenntnis, dass das Vorhaben in der geplanten Form nicht wirtschaftlich ist. Anders als beim klassischen Projekt ist der Abbruch hier kein Systemversagen, sondern ein vorgesehenes Ergebnis – vorausgesetzt, der Vertrag hat ihn geregelt.

Zu klären ist: Was ist bis dahin geschuldete und abzurechnende Leistung? Wem gehören die entstandenen Arbeitsergebnisse? Wer trägt Rückabwicklungs- und Migrationskosten? Und in welchem Zustand wird übergeben, damit ein anderer Dienstleister übernehmen kann? Wir regeln diese Fragen vorab – nicht in der Krise. Ist eine Fortführung nicht mehr möglich oder wirtschaftlich sinnvoll, müssen auch die Voraussetzungen und Folgen einer Kündigung im IT-Projekt sorgfältig geprüft werden.

Wie wir Sie unterstützen

Wir arbeiten für Auftraggeber wie für Dienstleister und kennen beide Kalkulationen:

• Gestaltung agiler Projektverträge – Rahmenverträge, Sprint-Vereinbarungen, agile Festpreismodelle
• Prüfung vorgelegter Verträge vor der Unterschrift, mit priorisierter Risikobewertung
• Führung und Begleitung der Vertragsverhandlungen
• Ausbalancierte Gewährleistungs- und Haftungsklauseln, die der agilen Arbeitsweise gerecht werden
• Laufende Projektbegleitung über alle Sprints hinweg [intern verlinken: IT-Projektbegleitung]
• Rettung notleidender agiler Projekte – Nachverhandlung, Eskalation, Fortführungsvereinbarung
• Durchsetzung Ihrer Rechte im Streit- und Abbruchfall, außergerichtlich und gerichtlich

Bei öffentlichen Auftraggebern kommt die Frage hinzu, wie sich agile Vorgehensmodelle mit dem Vergaberecht und den EVB-IT vereinbaren lassen. Wir begleiten Sie durch beide Anforderungsebenen.

Was Sie von uns erwarten können: über 25 Jahre Erfahrung im IT-Recht, Vertrautheit mit agilen Methoden ebenso wie mit Wasserfallprojekten und kurze Reaktionszeiten in kritischen Projektphasen. Wir lassen uns Sprint Reviews und Backlogs nicht erklären – wir verstehen sie.

Häufige Fragen zu agilen Projektverträgen

Sprechen Sie uns vor dem ersten Sprint an

Agile Projekte lassen sich nicht rückwirkend vertraglich reparieren. Der beste Zeitpunkt für die Vertragsgestaltung ist, bevor das Team steht.

Jetzt unsere Fachanwältin für IT-Recht kontaktieren!

Weitere Leistungen unserer Anwaltskanzlei