Wenn „agil“ als Etikett genügt – und plötzlich das ganze Projekt wackelt

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.

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. Doch beim Lesen zeigt sich: Es ist im Kern ein Dienstvertrag. Manchmal sogar ein Werkvertrag. Manchmal auch beides gleichzeitig, bloß nicht erkennbar geregelt. Und wenn es hart auf hart kommt, interessiert sich kein Gericht für das hübsche Etikett. Entscheidend bleibt, was tatsächlich geschuldet wurde.

Besonders tückisch ist die häufige Annahme, ein agiler Vertrag sei automatisch ein Dienstvertrag – weil die Leistungen doch fortlaufend, iterativ und ohne abgeschlossene Pflichtenhefte erfolgen. Hier beginnt die Ironie: Gerade bei unklaren Regelungen neigen Gerichte eher zum Werkvertrag, wenn am Ende doch etwas „Laufendes“ entstehen soll, etwa 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 – mit allen Folgen: Abnahme, Gewährleistung, Mängelrechte, Fristen, Nachbesserungspflichten.

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 sei, der nicht rechtlich relevant ist. Wenn dann der Auftraggeber später behauptet, man sei von einem „Erfolg“ ausgegangen, kann ein Gericht sagen: Wenn es am Ende funktionieren sollte, liegt ein Werkvertrag vor. Und dann steht der Dienstleister plötzlich mit abnahmepflichtigen Ergebnissen da, ohne dass je ein Abnahmeprozess beschrieben war.

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. Und wer möchte in einem komplexen IT-Projekt, dass ein Dritter später interpretiert, was „gemeint“ war?

Die Praxis zeigt: Viele „agile Verträge“ sind nicht agil, sondern schlicht unvollständig

Wer regelmäßig Softwareverträge prüft, kennt das Bild: Zwei Seiten, hübsch formatiert, voller guter Absichten. Meist ein bunter Mix aus Agentur-Marketing und generischen IT-Dienstleistungsklauseln. Funktioniert auf den ersten Blick, scheitert aber beim ersten Problem. Denn „wir arbeiten agil“ reicht nicht, wenn nicht definiert ist, was „agil“ bedeutet, welche rechtlichen Konsequenzen das hat und wie Sprints tatsächlich vergütet und abgeschlossen werden.

In vielen Verträgen fehlen elementare Bestandteile einer agilen Zusammenarbeit. 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 so etwas fehlt, wird im Streitfall aus einer Sprintlieferung schnell ein potentielles Werk – und der Dienstleister muss plötzlich nachbessern, obwohl das gar nicht vorgesehen war.

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. Dann kann § 640 BGB durch die Hintertür relevant werden, obwohl das 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.

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. Und irgendwann sagt der Auftraggeber: „Es ist noch nicht fertig, also zahlen wir nicht.“ – was rechtlich fatal sein kann.

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. Und genau hier liegt der Unterschied zwischen einem Softwarevertrag, der funktioniert, und einem Vertrag, der im Streitfall zur Belastung wird.

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

Viele Entwickler setzen agile Zusammenarbeit bewusst ein, um aus dem strengen Korsett des Werkvertrags auszubrechen. Frei nach dem Motto: „Wir machen Sprints, daher gibt es keine Abnahme.“ Doch gerade dieser Gedanke ist juristisch gefährlich. Denn agile Muster ähneln oft einem Werkvertrag – manchmal mehr als einem Dienstvertrag. Das 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. Und sobald ein Erfolg geschuldet ist, greift das Werkvertragsrecht. Ob das nun gewollt war oder nicht.

Auch Gerichte neigen bei unklaren Verträgen dazu, die wirtschaftliche Erwartung des Auftraggebers zu berücksichtigen. Wenn dieser nachvollziehbar davon ausgeht, dass er nach 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 sind, keine Werke.

Deshalb müssen agile Verträge sauber erklären, was ein Sprint ist, was nicht, welche Ergebnisse verwertbar sind, welche nicht, 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, Retros. Der Vertrag muss diese Mechanik spiegeln. Es genügt nicht, Scrum-Vokabular aufzunehmen. Der Vertrag muss:

— 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

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 kein Vergütungsanspruch. Ohne Definition of Done keine Klarheit, was geliefert werden musste. Und der Entwickler steht ohne Vertragsschutz da.

Ein anderes Beispiel: Eine Agentur setzt auf einen automatisierten Vertrag aus einem Generator. Schönes Layout, moderne Worte, aber keine rechtliche Substanz. Das Ergebnis: Ein hybrider Vertrag, halb Werkvertrag, halb Dienstvertrag, aber ohne Struktur. Juristisch ein Pulverfass. Die technische Methodik wird missverstanden, die rechtliche Mechanik nicht abgebildet. Und 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, der nur dann verlässlich funktioniert, wenn die rechtlichen Grundlagen stabil sind.

Ein sauberer Vertrag verhindert nicht nur Streit – er spart Kosten, Zeit, Ressourcen und schützt vor ungewollten Haftungsrisiken. Und er signalisiert Professionalität: Sowohl in Richtung Auftraggeber als auch im eigenen Unternehmen.

Fazit: Agil arbeitet nur gut, wer auch rechtlich agil baut – und zwar professionell

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.

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.