Agile Verträge: Risiken bei unklarer Regelung | IT-Medienrecht

Agile Softwareentwicklung: Das Etikett ersetzt keine rechtssichere Vertragsstruktur

Kaum ein Begriff hat sich in den vergangenen Jahren so schnell verbreitet wie „agile Softwareentwicklung“. Jeder kennt jemanden, der Sprints plant, Backlogs pflegt oder Daily Stand-ups abhält. Manche Projektverträge wirken inzwischen wie Modeartikel: Einmal „agil“ draufstempeln – und schon fühlt sich die ganze Zusammenarbeit modern an.

Doch kaum irgendwo ist die Diskrepanz zwischen Anspruch und rechtlicher Wirklichkeit so groß wie hier. Denn das Label „agil“ ersetzt keine Vertragsstruktur. Es ist entscheidend, die juristischen Rahmenbedingungen klar zu definieren, um Missverständnisse zu vermeiden.

In vielen Verträgen findet sich ein hübscher Absatz zu Scrum oder Kanban, oft sogar ein Abschnitt zu Rollen wie Product Owner oder Scrum Master. Beim Lesen zeigt sich jedoch: Es ist im Kern ein Dienstvertrag. Manchmal handelt es sich sogar um einen Werkvertrag, oder eine unklare Mischform aus beidem.

Kommt es zum Streitfall, interessiert sich kein Gericht für das bloße Etikett „agil“. Entscheidend bleibt stattdessen, was tatsächlich geschuldet und vertraglich vereinbart wurde. Eine klare Abgrenzung ist daher unerlässlich.

Besonders tückisch ist die häufige Annahme, ein agiler Vertrag sei automatisch ein Dienstvertrag. Dies geschieht, weil die Leistungen fortlaufend, iterativ und ohne abgeschlossene Pflichtenhefte erfolgen sollen. Hier beginnt die Ironie: Gerade bei unklaren Regelungen neigen Gerichte eher zum Werkvertrag.

Dies ist der Fall, wenn am Ende doch etwas „Laufendes“ entstehen soll. Dazu gehören beispielsweise eine lauffähige Software, ein Feature-Increment oder eine bestimmte Funktionsfähigkeit. Werden im Vertrag Ziele, Inkremente oder konkrete Ergebnisse beschrieben, kann dies bereits ausreichen, um eine werkvertragliche Struktur anzunehmen.

Eine solche Annahme hat weitreichende Folgen. Sie betrifft insbesondere Abnahme, Gewährleistung, Mängelrechte, Fristen und Nachbesserungspflichten, die alle dem Werkvertragsrecht unterliegen.

Ein häufiger Fall aus der Praxis: Der Auftragnehmer erklärt dem Auftraggeber, agile Softwareentwicklung sei „State of the Art“, „modern“ und „das, was man heute eben so macht“. Dabei wird – gewollt oder ungewollt – suggeriert, dass Abnahmen ohnehin nicht nötig seien oder dass jedes Sprint-Ergebnis nur ein Zwischenschritt ist, der nicht rechtlich relevant ist.

Wenn dann der Auftraggeber später behauptet, man sei von einem „Erfolg“ ausgegangen, kann ein Gericht zu dem Schluss kommen: Sollte am Ende ein funktionierendes Produkt entstehen, liegt ein Werkvertrag vor. Der Dienstleister steht dann plötzlich mit abnahmepflichtigen Ergebnissen da, obwohl nie ein Abnahmeprozess beschrieben war. Solche Szenarien können Sie durch eine präzise Vertragsgestaltung im Kontext agiler Arbeitsmethoden vermeiden.

Genau deshalb sind Vorworte, Definitionen, Rechtsklarstellungen und Gestaltungslogiken im Vertrag so wichtig. Ohne diese Struktur besteht die Gefahr, dass agiles Vokabular letztlich gegen den Auftragnehmer arbeitet. Ein agiler Softwarevertrag muss klar sagen, was getan wird und was nicht.

Andernfalls entscheidet das Gericht. Wer möchte schon in einem komplexen IT-Projekt, dass ein Dritter später interpretiert, was „gemeint“ war? Eine klare vertragliche Grundlage ist für den Projekterfolg unerlässlich.

Fehler in der Praxis: Viele „agile Verträge“ sind unvollständig

Wer regelmäßig Softwareverträge prüft, kennt das Bild: Zwei Seiten, hübsch formatiert, voller guter Absichten. Meist handelt es sich um einen bunten Mix aus Agentur-Marketing und generischen IT-Dienstleistungsklauseln. Dies funktioniert auf den ersten Blick, scheitert aber beim ersten Problem.

Denn „wir arbeiten agil“ reicht nicht aus, wenn nicht definiert ist:

• Was „agil“ bedeutet
• Welche rechtlichen Konsequenzen dies hat
• Wie Sprints tatsächlich vergütet und abgeschlossen werden

• Kein „Definition of Done“
• Kein „Definition of Ready“
• Keine klaren Sprint-Prozesse
• Keine Mechanik für Änderungswünsche
• Kein Abnahmeprozess
• Keine Fehlerklassifikation
• Kein Eskalationspfad
• Keine Budgetkappen
• Manchmal fehlt sogar der grundlegende Hinweis, dass ein Sprint nicht zu einem abnahmefähigen Werk führt, sondern nur zu einem Zwischenergebnis.

• Kein „Definition of Done“
• Kein „Definition of Ready“
• Keine klaren Sprint-Prozesse
• Keine Mechanik für Änderungswünsche
• Kein Abnahmeprozess
• Keine Fehlerklassifikation
• Kein Eskalationspfad
• Keine Budgetkappen

Manchmal fehlt sogar der grundlegende Hinweis, dass ein Sprint nicht zu einem abnahmefähigen Werk führt, sondern nur zu einem Zwischenergebnis. Wenn solche Elemente fehlen, wird im Streitfall aus einer Sprintlieferung schnell ein potenzielles Werk. Der Dienstleister muss dann plötzlich nachbessern, obwohl dies gar nicht vorgesehen war.

Probleme bei der Vergütung in agilen Verträgen

Ein klassisches Problem ist die Vergütung. Viele Verträge beschreiben Sprints, Story Points oder Velocity, ohne die Frage zu klären, ob Story Points verbindliche Leistungsgrößen darstellen oder nur Schätzwerte. Wird eine Story-Point-Schätzung als verbindliche Leistung interpretiert, entsteht ein verdeckter Festpreis.

In diesem Fall kann § 640 BGB durch die Hintertür relevant werden, obwohl dies nie gewollt war. Andere Verträge sehen monatliche Pauschalen vor, schweigen aber dazu, was geschieht, wenn ein Sprint abgelehnt wird oder der Auftraggeber keine Rückmeldung gibt. Wenn aber kein Abnahmeprozess existiert, bleibt die Vergütung oft aus.

Mitwirkungsregelungen und Projektverlauf

Gerade in agilen Verträgen ist der Auftraggeber nicht nur „Besteller“, sondern aktiver Teil des Entwicklungsprozesses. Fehlt eine saubere Mitwirkungsregelung, steht das gesamte Projekt auf wackeligen Beinen. Ohne klare Vorgaben zu Testdaten, Review-Terminen oder Feedback-Schleifen kann sich das Projekt unendlich ziehen.

Irgendwann sagt der Auftraggeber dann: „Es ist noch nicht fertig, also zahlen wir nicht.“ Dies kann rechtlich fatale Konsequenzen haben. Um solche Szenarien zu vermeiden, ist eine klare vertragliche Grundlage unerlässlich.

Wer glaubt, ein kleines Vertragsmuster aus dem Internet reiche aus, übersieht, dass agile Zusammenarbeit mehr ist als ein paar Meetings und ein Backlog. Es ist ein eigenes Steuerungsmodell, das sich im Vertrag widerspiegeln muss. Hier liegt der Unterschied zwischen einem Softwarevertrag, der funktioniert, und einem Vertrag, der im Streitfall zur Belastung wird. Mehr dazu, warum Verträge wichtig sind.

Der „agil“-Stempel schützt nicht vor werkvertraglichen Risiken

• Inkremente beschrieben werden, die „funktional nutzbar“ sein sollen
• Ergebnisse nach einem Sprint Review freigegeben werden
• ein Mindestziel definiert wird
• mehrere Module zusammenspielen sollen
• der Vertrag von einem „Endprodukt“ spricht

Dies zeigt sich besonders, wenn:

• Inkremente beschrieben werden, die „funktional nutzbar“ sein sollen
• Ergebnisse nach einem Sprint Review freigegeben werden
• ein Mindestziel definiert wird
• mehrere Module zusammenspielen sollen
• der Vertrag von einem „Endprodukt“ spricht

Diese Elemente erzeugen eine Erfolgsverpflichtung. Sobald ein Erfolg geschuldet ist, greift das Werkvertragsrecht. Dies gilt, ob es nun gewollt war oder nicht. Gerichte neigen bei unklaren Verträgen dazu, die wirtschaftliche Erwartung des Auftraggebers zu berücksichtigen.

Wenn dieser nachvollziehbar davon ausgeht, dass er am Ende mehr bekommt als Planungsartefakte, Meetings und ein paar Zeilen Code, wird man häufig ein werkvertragliches Element annehmen. Der Satz „Das ist agil, das ist eben so“ wird dann kaum überzeugen.

Es fehlt schlicht die vertragliche Grundlage, die klarstellt, dass Sprints Tätigkeiten und keine Werke sind. Daher müssen agile Verträge sauber erklären, was ein Sprint ist und was nicht, welche Ergebnisse verwertbar sind und welche nicht.

Ebenso wichtig ist es, zu definieren, wann etwas „fertig“ ist und wie diese Fertigstellung festgestellt wird. Ohne solche Regeln hilft kein Buzzword. Dann entscheidet das Gericht – und erfahrungsgemäß selten im Sinne des Auftragnehmers, wenn dieser das agile Modell „verkauft“ hat.

Warum eine juristisch saubere Vertragsarchitektur über Erfolg oder Scheitern entscheidet

Agile Softwareverträge funktionieren nur dann, wenn die juristische Architektur mit der technischen Methodik harmoniert. Ein modernes agiles Projekt hat Komponenten wie Backlog, Sprint-Planung, Reviews und Retros. Der Vertrag muss diese Mechanik spiegeln. Es genügt nicht, Scrum-Vokabular aufzunehmen.

Der Vertrag muss stattdessen:

• klarstellen, ob ein Werk- oder Dienstvertrag vorliegt
• die wirtschaftliche Erwartung der Parteien beschreiben
• definieren, wie ein Sprint akzeptiert wird
• regeln, wann ein Inkrement als Erfolg gilt
• festlegen, wie mit Verzögerungen, fehlender Mitwirkung, Scope Creep und Änderungswünschen umgegangen wird
• Lizenz- und IP-Regelungen eindeutig formulieren (z.B. in Bezug auf das Eigentum an Software)

Ein Beispiel aus der Praxis: Ein Entwickler liefert monatelang Sprint-Ergebnisse, der Auftraggeber testet sie, gibt Feedback, ändert Prioritäten. Alles läuft vermeintlich „agil“. Am Ende sagt der Auftraggeber: „Das war nicht abnahmefähig, wir zahlen nicht.“ Ohne Abnahmeprozess gibt es keinen Vergütungsanspruch. Ohne Definition of Done gibt es keine Klarheit, was geliefert werden musste.

Der Entwickler steht dann ohne Vertragsschutz da. Ein weiteres Beispiel betrifft die Verwendung von Standardverträgen.

Eine Agentur setzt auf einen automatisierten Vertrag aus einem Generator. Dies führt zu einem schönen Layout und modernen Worten, aber ohne rechtliche Substanz. Das Ergebnis ist ein hybrider Vertrag, halb Werkvertrag, halb Dienstvertrag, jedoch ohne Struktur.

Juristisch ist dies ein Pulverfass. Die technische Methodik wird missverstanden, die rechtliche Mechanik nicht abgebildet. Im Streitfall erklärt das Gericht: „Das ist ein Werkvertrag.“ Der Entwickler hat weder Abnahme noch Vergütungsmechanismen geregelt und bleibt auf dem Aufwand sitzen.

Gerade Start-ups oder kleine Softwarestudios unterschätzen, wie wichtig professionelle Verträge sind. Wer agil arbeitet, braucht nicht weniger Vertrag, sondern mehr. Genau wie bei einer komplexen Architektur müssen auch Vertragsbauteile präzise ineinandergreifen.

Agile Zusammenarbeit ist ein dynamischer Prozess. Er funktioniert nur dann verlässlich, wenn die rechtlichen Grundlagen stabil sind. Ein sauberer Vertrag verhindert nicht nur Streit – er spart Kosten, Zeit, Ressourcen und schützt vor ungewollten Haftungsrisiken. Zudem signalisiert er Professionalität: sowohl in Richtung Auftraggeber als auch im eigenen Unternehmen.

Fazit: Agil arbeitet nur gut, wer auch rechtlich agil baut

Es gibt kaum ein Themenfeld im IT-Recht, in dem die Diskrepanz zwischen Realität und Vertragspraxis so groß ist wie bei agilen Softwareverträgen. Ein agiler Vertrag ist kein Zettel mit ein paar Schlagworten, sondern ein umfangreiches Steuerungswerk.

Wer die Mechanik von Sprints, Backlogs, Priorisierungen und Inkrementen vertraglich nicht abbildet, riskiert erhebliche wirtschaftliche Nachteile. Wer sich als Auftragnehmer auf einen Dienstvertrag beruft, obwohl der Vertrag in Teilen ein werkvertragliches Ergebnis beschreibt, steht im Streitfall ungeschützt da.

Wer als Auftraggeber glaubt, dass agile Zusammenarbeit automatisch zu klaren Ergebnissen führt, wird überrascht sein, wie schnell Mängelrechte, Abnahmen und Gewährleistung ins Leere laufen können. Die Lösung ist nicht mehr Agilität, sondern mehr Professionalität.

Ein wirklich guter agiler Softwarevertrag benötigt eine präzise Vorbemerkung, eine klare Einordnung der Vertragsart, Definitionen für alle Begriffe, die Steuerungsmechanik für Sprints, Abnahmen, Mitwirkung, Vergütung, Lizenzrechte und vieles mehr. Das ist keine Formalität, sondern elementarer Bestandteil der Risikosteuerung.

Und genau hierfür steht meine Arbeit: Die Kombination aus technischem Verständnis, praktischer Projekterfahrung und tiefgreifender juristischer Expertise. Wer ein agiles Softwareprojekt startet oder bestehende Verträge prüfen lassen möchte, profitiert erheblich von einem Vertrag, der nicht nur modern klingt, sondern rechtlich belastbar ist.