Agile-Entwicklungsverträge in der Praxis

Ausgangslage und Einordnung

Warum eigene Vertragslogik für Agile?

Agile Softwareentwicklung arbeitet iterativ, inkrementell und empirisch. Anforderungen werden im Product Backlog priorisiert, in Sprints verfeinert und in User Stories umgesetzt. Planungssicherheit entsteht weniger durch eine starre Leistungsbeschreibung, sondern durch Taktung, Transparenz und Steuerung über Velocity, Sprint Reviews und eine belastbare Definition of Done. Klassische Entwicklungsverträge mit einmaliger, umfassender Spezifikation greifen hier zu kurz, weil Ziel, Weg und Aufwand nicht zu Projektbeginn vollständig feststehen.

Werk- oder Dienstvertrag?

Rechtlich stellt sich die Einordnung zwischen Dienstvertrag (§ 611 BGB) und Werkvertrag (§ 631 BGB). Bei agilen Setups lässt sich beides abbilden:

• Dienstvertraglich, wenn der Anbieter nur Tätigkeiten in Sprints schuldet und kein konkreter Erfolg definiert ist; Vergütung typischerweise time & material.
• Werkvertraglich, wenn pro Sprint oder pro Inkrement ein bestimmter Erfolg mit Abnahmefähigkeit vereinbart wird; maßgeblich sind Definition of Ready, Definition of Done, Akzeptanzkriterien und ein Abnahmeprozess (§ 640 BGB).

In der Praxis finden sich Mischmodelle: dienstvertragliche Erbringung der Sprintarbeit mit werkvertraglicher Teilabnahme einzelner inkrementeller Ergebnisse. Rechtssicherheit entsteht durch eindeutige Zuweisung, wann welcher Teil als „Werk“ mit Abnahmepflicht gilt und wann lediglich Tätigkeiten geschuldet sind.

Besondere Relevanz der Mitwirkung

Agile Methoden setzen intensive Mitwirkung des Auftraggebers voraus (Product Owner, schnelle Entscheidungen, Priorisierung, Testdaten, Zugangssysteme). Fehlt die Mitwirkung, drohen Verzögerungen. Eine saubere Mitwirkungsklausel mit Rechtsfolgen ist Pflicht; maßgeblich ist § 642 BGB (Annahmeverzug bei unterlassener Mitwirkung) sowie ergänzend klare Kooperations- und Eskalationsmechanismen.

Abgrenzung zum „normalen“ Entwicklungsvertrag

Der klassische Vertrag koppelt Vergütung und Termine an eine fixierte Leistungsbeschreibung (Lasten-/Pflichtenheft) mit einmaliger Endabnahme und Gewährleistung (§§ 633, 634 BGB). Agile Verträge arbeiten mit rollierenden Backlogs, Sprints, Teilabnahmen und Budgetkappen. Die zentrale Abgrenzung liegt im Steuerungsmechanismus: statt einmaliger Spezifikation wird die inhaltliche Zielerreichung sprintweise justiert. Das verlangt andere Vergütungs-, Abnahme- und Änderungsregeln.

Vertragsarchitektur eines Agile-Vertrags

Empfehlte Dokumentstruktur

Bewährt hat sich eine modulare Architektur:

• Rahmenvertrag/Master Service Agreement (MSA) mit allgemeinen Regelungen (IP, Haftung, Vertraulichkeit, Datenschutz, Konfliktlösung).
• Statement of Work (SOW) oder Leistungs- und Governance-Beschreibung für das agile Setup: Rollen, Events, Artefakte, Definition of Ready/Done, Schätzregeln, Abnahmeprozesse.
• Product-Backlog-Anhang mit initialen Epics/User Stories, Akzeptanzkriterien und Priorisierung.
• Sprint-Annex oder Sprint-Protokolle mit Sprintziel, Commitments, Story-Liste, Story-Point-Schätzungen, Testfällen und Abnahmeergebnissen.
• Change- und Budgetsteuerung (Capped Budget, Änderungsmechanismus, Eskalationsstufen).

Rollen und Verantwortlichkeiten

Die Rollen aus Scrum oder einem vergleichbaren Rahmen sollten juristisch „übersetzt“ werden:

• Product Owner: verantwortet Backlog-Priorisierung, Abnahmeentscheidungen, fachliche Vorgaben, Testdaten, Stakeholder-Management.
• Anbieterteam: liefert Inkremente, dokumentiert, testet entsprechend Definition of Done, weist Impediments aus.
• Delivery-Governance: Lenkungskreis mit festen Zyklen, verbindlichen Eskalationsregeln und Pflichten zur Protokollierung.

Wichtig ist die Zuweisung der Entscheidungsbefugnis: wer darf Stories freigeben, Abnahmen erteilen, Budgets verschieben. Schweigen und Untätigkeit müssen Rechtsfolgen auslösen (Fristen, Fiktionen).

Definition of Ready / Definition of Done

Die Definition of Ready legt fest, wann Stories sprintfähig sind (klarer Nutzen, Akzeptanzkriterien, Testdaten, Abhängigkeiten geklärt). Die Definition of Done determiniert Abnahmefähigkeit: Code-Standards, dokumentierte Tests, erfolgreiche Build-Pipelines, Sicherheitsprüfungen, Review. Diese beiden Definitionen sind der juristische Maßstab für Fälligkeit und Mangel.

Story Points, Velocity und Messbarkeit

Story Points sind ein relativer Komplexitätsmaßstab, keine Zeiteinheiten. Der Vertrag sollte das ausdrücklich festhalten, um Irrtümer auszuschließen. Gleichwohl benötigen Budget- und Kapazitätssteuerung belastbare Regeln, etwa:

• Umrechnungsklausel nur für Planungszwecke (z. B. durchschnittliche Velocity des Teams) ohne Gewährleistungscharakter.
• Kein Leistungsversprechen auf eine bestimmte Velocity; nur Best-Efforts unter Einhaltung der Methodik.
• Transparente Dokumentation in Sprint-Reports, Burn-Down/Burn-Up, Cumulative Flow Diagram.

Governance und Eskalation

Etablieren von Regelmeetings mit Protokollpflicht:

• Sprint Planning mit Story-Liste, Schätzung, Sprintziel, Risikoanalyse.
• Sprint Review mit Abnahmeentscheidungen, Freigabeprotokoll, Fiktion bei Fristversäumnis.
• Retrospektive mit Maßnahmenplan.
• Lenkungsausschuss monatlich zur Budgetsteuerung, Scope-Trade-offs, Risikomanagement.
  Fehlen Entscheidungen, greifen Eskalationsstufen bis hin zu Interimsentscheidungen des Lenkungskreises, um Stillstand zu vermeiden.

Leistungsbeschreibung, Abnahme und Mängelrechte

Ergebnisdefinition im agilen Kontext

Auch agile Projekte benötigen klare Ergebnismaßstäbe. Empfehlenswert ist die Kopplung von User Stories an messbare Akzeptanzkriterien. Für jedes Inkrement ist festzulegen, ob es als abnahmefähiges Werkteil gilt. Das ermöglicht Teilabnahmen (§ 640 BGB) und verlagert Gewährleistungsrisiken planvoll auf Sprint-Ebene.

Sprint- und Teilabnahme

Ein rechtssicherer Abnahmeprozess umfasst:

• Abnahmereife bei Erfüllung der Definition of Done und der Story-spezifischen Akzeptanzkriterien.
• Formale Abnahmeerklärung durch den Product Owner binnen einer Frist (z. B. fünf Werktage nach Review).
• Abnahmefiktion bei Untätigkeit (§ 640 Abs. 2 BGB), wenn der Anbieter die Abnahmereife angezeigt und eine angemessene Frist zur Erklärung gesetzt hat.
• Dokumentierte Mängelklassen; bei geringfügigen Mängeln zulässige Abnahme unter Vorbehalt.

Bewährt ist ein Sprint-Abnahmeprotokoll mit:

• Liste der fertiggestellten Stories.
• Testergebnisse und Nachweise.
• Entscheidung des Product Owners je Story (abgenommen, abgenommen unter Vorbehalt, abgelehnt mit Begründung).
• Frist zur Nacherfüllung bei abgelehnten Stories.

Gewährleistung und Haftung im Werkteil

Für als Werk definierte Inkremente gelten die Mängelrechte (§ 634 BGB): Nacherfüllung, Selbstvornahme, Minderung, Rücktritt, Schadensersatz. Die Verjährung kann sachgerecht bemessen werden (§ 634a BGB), häufig 12 Monate im B2B-Verhältnis für Standard-Softwarebestandteile; bei individuell erstellter Software sind differenzierte Fristen üblich. Bei rein dienstvertraglichen Leistungen greifen die allgemeinen Leistungsstörungsrechte (§§ 280 ff. BGB).

Change-Mechanismus

Agile Projekte verändern Scope und Prioritäten regelmäßig. Eine Change-Klausel sollte regeln:

• Wer Change-Requests anstoßen darf.
• Bewertung des Impakts auf Budget, Termin, Qualität.
• Entscheidung und Protokollierung im Lenkungsausschuss oder im Sprint Planning.
• Automatischer Budget- oder Cap-Abgleich bei Scope-Zuwachs.
• Keine konkludenten Änderungen durch bloße Diskussionen in Tools; es braucht formale Festlegung.

Tests, Qualität und Security

Die Definition of Done sollte zwingende Qualitätsanforderungen enthalten: Code-Linting, Unit-Tests mit Mindestabdeckung, automatisierte Builds, Peer Reviews, Sicherheits-Checks (z. B. Dependency-Scanning), Protokollierung. Für Security-relevante Projekte sind zusätzliche Pflichten (Bedrohungsmodell, Penetrationstests, Notfallpläne) zu definieren. So werden Qualitätsdiskussionen justiziabel.

Vergütung, Budgetsteuerung und Controlling

Vergütungsmodelle im Überblick

Vier Modelle dominieren:

• Time & Material mit Cap: Abrechnung nach Stundensätzen, Obergrenze als Budgetsteuerungsinstrument.
• Sprintpauschalen: Festpreis je Sprint bei vereinbarter Kapazität und Teamzuschnitt; Anpassung bei Teamwechseln.
• Preis je Story Point: Vergütung pro Punkt; erfordert klare Regeln für Schätzung, Re-Schätzung und Ausschlüsse. Wichtig ist die Klarstellung, dass Punkte kein Zeitversprechen sind.
• Hybrid: T&M für Discovery/Architektur und Werkvergütung für definierte Inkremente oder Releases.

Die Wahl hängt von Risikobereitschaft und Reifegrad des Backlogs ab. Ein dynamischer Wechsel je Projektphase ist möglich, muss aber vorab vorgesehen werden.

Budgetkappen, Stop-Loss und Priorisierung

Unverzichtbar sind harte Budgetkappen mit Stop-Loss-Mechanik: Annäherung an 80 % des Cap löst Pflicht zur Budgetkonferenz aus; bei 100 % Cap Stop der Entwicklung, bis schriftliche Erhöhung erfolgt. Parallel wird das Backlog so priorisiert, dass maximaler Business Value innerhalb des Caps realisiert wird. Kein „automatisches“ Überziehen des Caps durch Mehraufwand.

Transparenz- und Reportingpflichten

Rechtlich durchsetzbare Transparenz entsteht durch:

• Wöchentliche Aufwandsreports je Rolle und Story.
• Sprint-Reports mit Velocity, Stories Done/Not Done, Impediments, Burn-Down.
• Monatsreport an den Lenkungsausschuss mit Budgetverbrauch, Forecast, Risiken, Maßnahmen.
• Auditrecht auf die Projekttools und Repositories nach Ankündigung.

Fehlt diese Transparenz, kippt das Risikoprofil. Reporting wird daher zur Kardinalpflicht.

Nebenkosten und Drittleistungen

Reisekosten, Lizenzen, Cloud-Ressourcen, Testgeräte und Subunternehmer sind separat zu regeln. Subprozessoren nur mit Zustimmung, mit gleicher Vertraulichkeit und denselben Sicherheitsstandards. Drittsoftware muss lizenziert sein; Open-Source-Einsatz erfordert Compliance-Regeln.

Beispielhafte Vergütungsklauseln (Auszug)

• Time & Material mit Cap: „Der Anbieter rechnet monatlich nach tatsächlichem Aufwand gemäß Anlage Preisliste ab. Die Gesamtvergütung ist auf den Budgetrahmen begrenzt. Bei Erreichen von 80 % des Budgetrahmens findet eine Budgetkonferenz statt; ohne schriftliche Budgeterhöhung ruht die Leistungspflicht nach Ausschöpfen des Budgetrahmens.“
• Sprintpauschale: „Je Sprint wird eine Pauschale fällig, die die in Anlage Teamzuschnitt ausgewiesenen Rollen umfasst. Änderungen des Teamzuschnitts bewirken eine proportionale Anpassung der Pauschale ab dem Folgesprint.“
• Story-Point-Modell: „Die Parteien vereinbaren eine Vergütung pro Story Point. Story Points dienen als relativer Komplexitätsmaßstab und stellen keine Zeiteinheit dar. Eine bestimmte Velocity wird nicht geschuldet.“

Mitwirkung, IP, Datenschutz und Compliance

Mitwirkungspflichten und Rechtsfolgen

Pflichten des Auftraggebers:

• Benennung eines entscheidungsbefugten Product Owners.
• Rechtzeitige Bereitstellung von Testdaten, Zugängen, Ansprechpartnern.
• Teilnahme an Sprint-Zeremonien; Abnahmeentscheidungen innerhalb der Fristen.
• Priorisierung und Klärung von Abhängigkeiten.

Rechtsfolgen bei Verzögerung:

• Leistungsverweigerungsrecht des Anbieters bei fehlender Mitwirkung.
• Terminverlängerung und Mehraufwandvergütung.
• Zahlungsfälligkeit für Leerlauf gem. § 642 BGB.
• Eskalation bis hin zur außerordentlichen Kündigung bei anhaltenden Pflichtverletzungen (§ 314 BGB).

Rechte an Arbeitsergebnissen

Für kundenspezifische Software sind ausschließliche, zeitlich und räumlich unbeschränkte Nutzungsrechte am Quell- und Objektcode üblich (§§ 31, 69a ff. UrhG). Wichtig sind:

• Rechtekette bei Subunternehmern; Einräumung spätestens mit Zahlung fällig.
• Herausgabe- und Übergabepflichten: Quellcode, Build-Skripte, Dokumentation, Infrastruktur- und Secrets-Übersicht.
• Beschränkungen auf Standardbausteine des Anbieters (Frameworks, Libraries, Tooling), die nur einfache Nutzungsrechte begründen, sofern das vereinbart ist.
• Verzicht oder Ausgestaltung des Urheberbenennungsrechts (§ 13 UrhG) in B2B-Projekten.

Open Source und Einsatz von KI-Assistenz

Open-Source-Komponenten sind zulässig bei vorheriger Freigabe und dokumentierter Lizenzprüfung. Copyleft-Lizenzen (z. B. GPL) bedürfen gesonderter Zustimmung, wenn eine Quelloffenlegung droht. Eine OSS-Bill of Materials (SBOM) ist bereitzustellen; Sicherheitsupdates sind Teil der Wartung.

Bei Nutzung von KI-Assistenzsystemen in der Entwicklung sind Regeln zu treffen:

• Keine Einspeisung vertraulicher Kundendaten in externe Modelle ohne Freigabe.
• Dokumentation der Herkunft wesentlicher Codeabschnitte.
• Sicherstellung, dass keine Rechte Dritter verletzt werden.
• Klare Verantwortlichkeit für Qualität und Sicherheit des von KI generierten Codes.

Datenschutz und Geheimnisschutz

Verarbeitet der Anbieter personenbezogene Daten des Auftraggebers, ist ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO erforderlich (TOMs, Subprozessoren, Auditrechte, Löschkonzept). Geschäftsgeheimnisse werden durch das GeschGehG geschützt; erforderlich sind Vertraulichkeitsklauseln, Zugriffskontrollen, Need-to-know-Prinzip und ein Schutzstufenmodell für Quellcode und Artefakte.

Betrieb, Wartung, SLA

Nach der Entwicklung schließt häufig ein Wartungs- und Supportvertrag an. Inhalt:

• Störungsannahme, Reaktions- und Behebungszeiten (SLA) mit abgestuften Schweregraden.
• Patch- und Release-Management, Kompatibilitätspflege.
• Sicherheitsmonitoring und Incident-Response-Prozesse.
• Vergütung als Retainer mit Kontingenten plus Zusatzaufwand zu Sätzen des MSAs.

Haftung, Kündigung, Exit – Vor- und Nachteile im Überblick

Haftung und Limitierungen

Haftungsregeln müssen die Kardinalpflichten und typische Projektrisiken abbilden:

• Unbeschränkte Haftung für Vorsatz und grobe Fahrlässigkeit.
• Körper- und Gesundheitsschäden sowie Produkthaftung unberührt.
• Bei einfacher Fahrlässigkeit Haftung nur für Kardinalpflichtverletzungen, begrenzt auf den typischen, vorhersehbaren Schaden (§§ 280, 276 BGB).
• Datenverlustschäden nur, soweit regelmäßige Datensicherung vereinbart und nachweisbar ist.
• Haftungscaps je Vertragsjahr, Ausschluss von entgangenem Gewinn und indirekten Schäden, soweit rechtlich zulässig. Klauselkontrolle nach §§ 305 ff. BGB beachten; § 309 BGB gilt zwar primär im B2C, wirkt aber als Leitbild in B2B-Konstellationen über § 307 BGB.

Kündigungsrechte

Gestaffelte Kündigungslogik:

• Außerordentliche Kündigung aus wichtigem Grund (§ 314 BGB) bei schweren Pflichtverletzungen.
• Werkvertragliche freie Kündigung (§ 648 BGB) für definierte Werkteile, mit Vergütung der bis dahin erbrachten Leistungen und entgangenen Gewinnanteilen.
• Dienstvertragliche Kündigung nach § 621 BGB oder vertraglich festgelegt, mit Abrechnung der Sprints bis zum Wirksamwerden.
• Sprintweise Kündigungsmöglichkeit zum Sprintende; klare Folgen für Budget, Repositories und Lizenzen.

Exit- und Übergaberegeln

Ein sauberer Exit verhindert Lock-in:

• Pflicht zur Übergabe von Quellcode, Dokumentation, Tickets, Architektur- und Betriebsdokumenten in gängigen Formaten.
• Übergabe der Zugänge und Rechte an Repositories, CI/CD, Cloud-Accounts; zweistufiges Verfahren mit Abnahme der Übergabe.
• Unterstützung bei der Transition an Dritte zu definierten Sätzen.
• Optional Software-Escrow für kritische Komponenten.
• Löschung oder Rückgabe vertraulicher Daten nach dokumentierter Checkliste.

6.4. Vorteile und Nachteile des agilen Vertragsmodells

Vorteile für Auftraggeber:

• Frühe Mehrwerte durch inkrementelle Lieferungen; Transparenz über Fortschritt und Budget.
• Möglichkeit zur Prioritätsverschiebung basierend auf Geschäftsnutzen.
• Risikoentlastung durch Teilabnahmen und Stop-Loss-Mechanismen.

Vorteile für Anbieter:

• Realistische Steuerung des Scope, weniger Nachtragsstreit.
• Planbare Teams durch Sprinttaktung und Governance.
• Vergütung nah am Aufwand reduziert Kalkulationsrisiken.

Nachteile für Auftraggeber:

• Weniger Preis- und Terminfixität, wenn Backlog unreif.
• Erhöhte Mitwirkungsintensität; Ressourcenbindung im Fachbereich.
• Gefahr von „Scope Creep“, wenn Governance schwach ist.

Nachteile für Anbieter:

• Hoher Dokumentations- und Reportingaufwand.
• Abhängigkeit von Mitwirkung und Produktentscheidungen des Auftraggebers.
• Diskussionen um Story-Point-Schätzungen und Velocity, wenn vertraglich schlecht gefasst.

Praxis-Checkliste zentraler Klauseln

Leistungs- und Ergebnisdefinition

• Klare Definition of Ready/Done und Story-spezifische Akzeptanzkriterien.
• Regel, welche Artefakte in die Abnahme einfließen (Code, Tests, Dokumentation).

Abnahme

• Sprint-Review als Abnahmefenster mit Frist zur Erklärung.
• Abnahmefiktion bei Untätigkeit; Abnahme unter Vorbehalt bei geringfügigen Mängeln.

Vergütung und Budget

• Wahl des Vergütungsmodells mit Cap und Stop-Loss.
• Reportingpflichten, Forecast, Eskalationsstufen.
• Regeln zu Change-Requests und deren Budgetwirkung.

Mitwirkung

• Namentlicher Product Owner, Verfügbarkeitsfenster, Entscheidungsfristen.
• Folgen bei Mitwirkungsmängeln (§ 642 BGB), inklusive Vergütung von Stillstandszeiten.

IP und Übergabe

• Rechtekette, Umfang der Rechte (§§ 31, 69a ff. UrhG), Zeitpunkt des Übergangs.
• Herausgabepflichten und Exit-Checkliste, Escrow optional.

Open Source und KI

• Freigabeprozess, SBOM, Copyleft-Regeln.
• Einsatzregeln für KI-Assistenz, Schutz von Geschäftsgeheimnissen.

Datenschutz und Sicherheit

• AVV nach Art. 28 DSGVO bei Datenverarbeitung, TOMs, Subprozessoren, Audit.
• Security-Standards in der Definition of Done, Incident-Response.

Haftung

• Staffelung nach Verschuldensgraden, Haftungscap, Ausschlüsse im rechtlichen Rahmen.
• Besondere Risiken (z. B. Datenverlust) und Sicherungsobliegenheiten.

Kündigung und Streitlösung

• Gestaffelte Kündigungsrechte (Sprintende, § 648, § 314).
• Mediations- oder Schlichtungsklausel vor gerichtlichen Schritten.

Formulierungsbeispiele

Mitwirkung:
„Der Auftraggeber stellt einen entscheidungsbefugten Product Owner zur Verfügung, der an allen Sprint-Zeremonien teilnimmt und binnen fünf Werktagen Entscheidungen trifft. Unterbleiben erforderliche Mitwirkungen, verlängern sich Fristen angemessen; der Anbieter kann Stillstandszeiten und Mehraufwand abrechnen. § 642 BGB bleibt unberührt.“

Abnahme:
„Die Parteien führen am Ende eines jeden Sprints ein Review durch. Der Anbieter zeigt die Abnahmereife an. Der Auftraggeber erklärt binnen fünf Werktagen die Abnahme je Story oder benennt konkrete Mängel. Erfolgt keine Erklärung, gilt die Abnahme als erteilt (§ 640 Abs. 2 BGB). Geringfügige Mängel hindern die Abnahme nicht; die Nacherfüllung erfolgt innerhalb angemessener Frist.“

Story Points:
„Story Points sind ein relativer Komplexitätsmaßstab und stellen keine Zeiteinheit dar. Eine bestimmte Velocity wird nicht geschuldet. Schätzungen dienen ausschließlich der Kapazitäts- und Budgetplanung.“

Vergütung Cap:
„Die Vergütung erfolgt auf T&M-Basis gemäß Anlage Preisliste, begrenzt durch den Budgetrahmen. Bei Erreichen von 80 % des Budgetrahmens erfolgt eine Budgetkonferenz; nach Ausschöpfen des Rahmens ruht die Leistungserbringung, bis eine schriftliche Budgeterhöhung vorliegt.“

Rechteübertragung:
„Mit Abnahme und Zahlung erhält der Auftraggeber die ausschließlichen, räumlich und zeitlich unbeschränkten Nutzungsrechte an den individuellen Arbeitsergebnissen einschließlich Quellcode und Dokumentation. Standardbausteine des Anbieters verbleiben beim Anbieter; hieran erhält der Auftraggeber einfache Nutzungsrechte in dem zur Verwendung der Arbeitsergebnisse erforderlichen Umfang.“

Open Source:
„Der Einsatz von Open-Source-Komponenten bedarf der Freigabe. Der Anbieter stellt eine SBOM zur Verfügung und gewährleistet Lizenz-Compliance. Copyleft-Lizenzen, die eine Offenlegung der Auftraggebersoftware auslösen, bedürfen gesonderter Zustimmung.“

Haftung:
„Für Vorsatz und grobe Fahrlässigkeit haftet der Anbieter unbeschränkt. Bei einfacher Fahrlässigkeit haftet er nur für die Verletzung wesentlicher Vertragspflichten, begrenzt auf den vorhersehbaren, typischen Schaden. Die Haftung für Schäden aus der Verletzung des Lebens, des Körpers oder der Gesundheit bleibt unberührt.“

Kündigung:
„Jede Partei kann aus wichtigem Grund kündigen (§ 314 BGB). Der Auftraggeber kann werkvertragliche Teile gemäß § 648 BGB frei kündigen; bereits erbrachte Leistungen sind zu vergüten. Kündigungen sind zum Sprintende möglich, sofern nicht ein wichtiger Grund eine fristlose Beendigung rechtfertigt.“

Exit:
„Der Anbieter unterstützt die Transition auf einen Dritten für bis zu 20 Personentage nach Vertragsende. Quellcode, Repositories, CI/CD-Skripte, Dokumentation und Zugangsdaten werden vollständig und in gängigen Formaten übergeben; die Übergabe unterliegt einer Abnahme durch den Auftraggeber.“

Fazit

Agile Entwicklungsverträge funktionieren, wenn das juristische Korsett die Methode nicht erstickt, sondern operationalisiert: klare Governance, sprintfähige Ergebnisdefinitionen, belastbare Abnahme- und Mängelmechanik, transparente Budgetsteuerung, harte Mitwirkungspflichten und ein ausgewogenes Vergütungsmodell. Die bewusste Einordnung einzelner Projektteile als Werk oder Dienst vermeidet spätere Streitigkeiten um Abnahme, Gewährleistung und Haftung. Wer die agilen Artefakte (Backlog, Definition of Done, Sprintprotokolle) als rechtsverbindliche Messlatte etabliert und mit einem straffen Change- und Reportingregime verknüpft, erhält ein praxistaugliches, revisionssicheres Vertragswerk, das Flexibilität erlaubt, ohne Rechtssicherheit zu opfern.