So gestalten wir Ihren agilen Softwareentwicklungsvertrag
Scrum- oder Kanban-Projekt rechtssicher strukturieren: Rahmenverträge, Sprint-SoWs und Change-Request-Mechaniken für Auftraggeber und Agenturen.
Agile Entwicklung lebt von Flexibilität. Backlogs ändern sich, Scope wandert, Sprint-Ergebnisse sehen am Ende anders aus als im Kick-Off. Das deutsche Vertragsrecht dagegen liebt Klarheit: ein Erfolg, eine Abnahme, eine Gewährleistungsfrist. Genau in dieser Spannung entstehen die teuersten Fehler agiler IT-Projekte - auf beiden Seiten des Tisches. Eine übergreifende Einordnung dieser Risiken bietet unsere Rechtsberatung im IT-Recht.
Wer einen agilen Softwareentwicklungsvertrag unterschreibt, ohne die Bruchstellen zwischen Werkvertrag und Dienstvertrag, zwischen Definition of Done und BGB-Abnahme, zwischen Sprint-Velocity und Festpreis verstanden zu haben, importiert Streitpotenzial direkt in sein Projekt.
Dieser Leitfaden beantwortet drei Fragen:
- Wann ist Ihr Scrum-Vertrag juristisch Werkvertrag, wann Dienstvertrag und wann ein gefährlicher Mischvertrag?
- Welche Klauseln entscheiden in der Praxis über Marge, Budget und Reputation beider Seiten?
- Welche Folgen drohen, wenn Abnahme, Change-Request-Mechanik, IP-Rechte oder Nearshoring unsauber geregelt sind?
Was ist ein agiler Softwareentwicklungsvertrag?
Das unterscheidet ihn grundlegend vom Wasserfallmodell. Im Wasserfall definiert ein Lastenheft am Anfang, was später abgenommen wird. Im agilen Projekt sind Lastenheft und Produkt eine einzige, laufende Diskussion. Das ist methodisch der Sinn der Sache - und juristisch die Quelle fast aller Probleme.
Werkvertrag oder Dienstvertrag? Die juristische Kernfrage
Im Kern entscheidet eine einzige Frage über fast alle Folgekonflikte: Ist der Vertrag ein Werkvertrag oder ein Dienstvertrag?
Der Bundesgerichtshof hat in seinem Urteil vom 25. März 2010 (Az. VII ZR 224/08) entschieden, dass ein Vertrag über die Anpassung einer Software an die konkreten Bedürfnisse des Auftraggebers nebst Schnittstellenprogrammierung als einheitlicher Werkvertrag einzuordnen ist, weil geschuldet die Herstellung eines funktionsfähigen Gesamtergebnisses ist und nicht die reine Programmiertätigkeit.
Typische Indizien für einen Werkvertrag
- Definierbares Endprodukt – Ein konkreter Gegenstand wie ein Buchungsportal, eine Onboarding-App oder eine interne Middleware, der am Ende steht.
- Abnahme einzelner Inkremente – Sprint-Ergebnisse oder die Gesamtlieferung werden durch den Kunden formal abgenommen.
- Erfolgsbezogene Vergütung – Meilenstein- oder Release-Zahlungen statt reiner Stundenkontingente ohne Liefergegenstand.
- Klare Übergabe von Code und Rechten – Source-Code und Nutzungsrechte gehen eindeutig an den Auftraggeber über.
Sobald der Auftragnehmer ein abnahmefähiges Inkrement schuldet, ist die Werkvertrags-Logik nicht mehr wegzuverhandeln, auch wenn im Vertrag “Consulting Agreement” oder “Development Services” steht.
Typische Indizien für einen Dienstvertrag
Ein echter Dienstvertrag liegt nur dann vor, wenn die Tätigkeit selbst geschuldet wird und der Erfolg in der Verantwortung des Auftraggebers liegt. In agilen Projekten ist das die Ausnahme, nicht die Regel. Typische Konstellationen sind:
- Agile Coaching oder Scrum-Master-Stellung, die nur den Prozess begleitet.
- Pure Team-Gestellung (Bodyleasing), bei der der Kunde die fachliche Führung vollständig übernimmt.
- Dauerhafte technische Begleitung ohne definiertes Projektergebnis.
Wer ein komplettes Scrum-Team stellt, das unter dem Product Owner des Kunden arbeitet, und das als “Dienstvertrag” bezeichnet, bewegt sich bereits im Grenzbereich zur Arbeitnehmerüberlassung. Dazu gleich mehr.
Der Mischvertrag und die AGB-Falle
Viele Agenturen versuchen den Mittelweg: Rahmenvertrag als Dienstvertrag, einzelne Sprint-SoWs als Werkvertrag. Das kann funktionieren, wird aber zum Problem, wenn die Vertragsdokumente sich widersprechen oder Standardklauseln verwenden.
Bei Auslegung von Vertragsklauseln, die vom Verwender einseitig in den Vertrag eingebracht werden, gehen Zweifel zu seinen Lasten (§ 305c Abs. 2 BGB).
Konkret bedeutet das für Dienstleister: Wenn Sie den Vertrag gestellt haben und eine Klausel mehrdeutig ist, entscheidet das Gericht zu Ihrem Nachteil. Wer Werkvertragsrecht ausschließen will, muss das glasklar und einzelfallgerecht formulieren - nicht in einem Template, das “für beide Vertragstypen funktioniert”.
Tipp von Rechtsanwalt Dr. Sener Dincer:
“In der Praxis sehen wir fast keine reinen Dienstverträge für Scrum-Projekte. Was wir sehen, sind Verträge, die Dienstvertrag sagen und Werkvertrag leben. Diese Lücke erzeugt später genau den Streit, den wir dann schlichten müssen. Wir gestalten den Vertrag lieber bewusst als Rahmen-Werkvertrag mit klarer Sprint-Teilabnahme - das ist sauberer und fällt bei einem Gerichtsprozess nicht in sich zusammen.”
Unsicher, ob Ihr agiler Vertrag rechtlich trägt? Wir prüfen Rahmenvertrag und Sprint-SoWs in einer kostenfreien Ersteinschätzung.
Kostenlose Anfrage- Kostenlos beraten
- Kein Risiko, 100% vertraulich
Die häufigsten Fehler in Scrum-Verträgen
Agile Verträge scheitern in der Regel nicht an einer einzelnen falschen Klausel, sondern an einer Summe unscharfer Regelungen, die sich im Projektverlauf gegenseitig verstärken. Aus unserer Mandatspraxis und der Branchendiskussion tauchen sechs Fehler immer wieder auf.
Festpreis für Scrum - das Einkaufs-Dilemma
Der Klassiker: Der Einkauf auf Auftraggeberseite verlangt einen Festpreis, weil er sein Budget planbar machen muss. Die Agentur unterschreibt, obwohl das Product Backlog am Kick-Off noch halb leer ist. Nach Sprint 3 zeigt sich, dass der Scope größer war als geschätzt. Die Agentur senkt still die Qualität, der Auftraggeber wundert sich, das Vertrauen kippt.
Festpreis und Scrum sind nicht per se unvereinbar - aber nur, wenn die Volatilität des Backlogs vertraglich adressiert ist. Das gelingt entweder über gestaffelte Tranche-Festpreise pro Release-Paket, über einen Cap-Preis mit variabler Scope-Tiefe oder über Hybrid-Modelle mit Target Cost und Incentive-Sharing. Ein reiner Festpreis auf ein offenes Backlog ist vertraglich ein Sprengsatz für beide Seiten.
Scope-Volatilität ohne Change-Request-Mechanik
In agilen Projekten wandert Scope täglich. Das ist gewollt. Nicht gewollt ist, dass niemand weiß, wer dafür zahlt. Wenn die Change-Request-Mechanik im Vertrag auf eine halbe DIN-A4-Seite reduziert ist (“Änderungen sind möglich, werden im Einvernehmen umgesetzt”), entsteht ein perfekter Nährboden für Konflikt.
In der Praxis kommen drei Änderungstypen vor: bloße Klarifikationen (kein CR nötig), Priorisierungs-Shifts innerhalb des bestehenden Scopes (kein Preisaufschlag) und echte Scope-Erweiterungen (CR-pflichtig). Ein brauchbarer Vertrag unterscheidet diese drei Kategorien, definiert einen schriftlichen Antrags- und Aufwandsprozess und legt fest, was passiert, wenn der CR abgelehnt wird. Fehlt diese Mechanik, entsteht “Weekly Change Creep”: sieben kleine “selbstverständliche” Änderungen pro Woche, die am Sprint-Ende 30 Prozent Scope-Wachstum ohne einen einzigen formalen CR bedeuten.
Definition of Done gegen BGB-Abnahme
Agile Teams arbeiten mit einer Definition of Done (DoD): Code-Review passed, Unit-Tests grün, Story in Staging deploybar. Das juristische Äquivalent ist die Abnahme nach § 640 BGB. Beides wird in der Praxis häufig als dasselbe behandelt - was ein Fehler ist.
Die DoD ist ein internes Qualitätsversprechen des Entwicklerteams. Die Abnahme ist eine Vertragserklärung des Bestellers, dass das Werk vertragsgemäß hergestellt ist. Wenn der Kunde die DoD nachträglich um Security-Scans, Lasttests oder Integrationstests erweitert, weil der Vertrag DoD und Abnahme gleichsetzt, kippt die Kalkulation der Agentur. Wenn der Kunde umgekehrt gar nicht formal abnimmt, sondern Sprint-Reviews mit Stillschweigen beendet, droht die fiktive Abnahme nach § 640 Abs. 2 BGB - und damit der Verlust wichtiger Mängelrechte.
Das Oberlandesgericht Frankfurt am Main hat in seinem Urteil vom 17. Juli 2017 (Az. 5 U 152/16) zu einem Softwareentwicklungsprojekt im Scrum-Verfahren entschieden, dass in der Beauftragung weiterer Sprints nach monatlicher Abrechnung nach Zeitaufwand eine konkludente Abnahme der bis dahin erbrachten Teilleistungen liegen kann; die Vertragsqualifikation als Werk- oder Dienstvertrag hat das Gericht dabei ausdrücklich offengelassen und sich auf die konkrete Vertragsgestaltung gestützt.
Das heißt in der Praxis: Wer als Auftraggeber eine Sprint-Tranche bezahlt und die nächste startet, ohne Mängel anzumelden, riskiert, dass das Gericht darin eine stillschweigende Abnahme sieht - mit der Folge, dass Mängelrechte eingeschränkt und die Gewährleistungsfrist anläuft. Die Entscheidung zeigt auch, dass eine klare Vertragsgestaltung (Werkvertrag oder Dienstvertrag) die Auseinandersetzung entscheidend vereinfacht; ein BGH-Grundsatzurteil zur Rechtsnatur agiler Scrum-Verträge steht nach wie vor aus.
Scheinselbstständigkeit und Arbeitnehmerüberlassung
Scrum-Teams sind eng verzahnt. Der Product Owner priorisiert, das Team committet, der Scrum Master räumt Hindernisse weg. Je enger die Integration, desto höher das Risiko, dass aus dem externen Dienstleister ein faktischer Arbeitnehmer wird.
Maßgeblich für die sozialversicherungsrechtliche Einordnung als abhängige Beschäftigung ist nach § 7 Abs. 1 SGB IV die tatsächliche Weisungsgebundenheit und Eingliederung in die Arbeitsorganisation des Auftraggebers, unabhängig von der vertraglichen Bezeichnung.
Für die Praxis heißt das: Ein Freelancer, der täglich im Daily steht, Sprint-Planning mit dem Kunden macht, Urlaub mit dem Product Owner abspricht und seit 18 Monaten ausschließlich für einen Auftraggeber arbeitet, wird von der Deutschen Rentenversicherung regelmäßig als scheinselbstständig eingestuft. Die Konsequenzen sind hart: Beitragsnachzahlungen bis zu vier Jahren rückwirkend, bei Vorsatz bis zu 30 Jahren, strafrechtliche Risiken nach § 266a StGB.
Gleichzeitig hat die jüngere Rechtsprechung deutlich gemacht, dass allein die Teilnahme an Scrum-Zeremonien nicht automatisch zur Scheinselbstständigkeit führt, solange der Freelancer ausreichend unternehmerische Freiräume behält.
Das Landessozialgericht Baden-Württemberg hat in seinem Urteil vom 17. Dezember 2021 (Az. L 8 BA 1374/20) entschieden, dass ein in Scrum-Sprints tätiger Programmierer als selbstständig einzustufen sein kann, wenn er eigenständig über die Übernahme einzelner Arbeitspakete entscheidet, nicht weisungsgebunden in die Betriebsorganisation eingegliedert ist und aufgrund seiner Spezialkenntnisse ein deutlich über den Löhnen vergleichbarer Angestellter liegendes Honorar erhält.
Das Gericht hat dabei insbesondere klargestellt, dass räumliche Präsenz im Büro des Auftraggebers aus sicherheitstechnischen Gründen, die Teilnahme an Daily Standups und die technische Abnahme durch den Fachbereich des Kunden allein noch keine Eingliederung im sozialversicherungsrechtlichen Sinne begründen. Bestätigt wurde diese Linie 2025 erneut (LSG Baden-Württemberg, 30.04.2025 - L 5 BA 79/24): Die agile Arbeitsweise mit kurzen Sprints ist der Methode geschuldet, nicht Ausdruck einer abhängigen Beschäftigung. Entscheidend bleibt die Gesamtschau aller Indizien.
Wer allerdings versucht, das Risiko durch die Zwischenschaltung einer Ein-Personen-GmbH zu neutralisieren, unterliegt einem weit verbreiteten Irrtum.
Das Bundessozialgericht hat in seinem Urteil vom 20. Juli 2023 (Az. B 12 R 15/21 R) entschieden, dass die Zwischenschaltung einer Ein-Personen-GmbH keinen Schutz vor der Feststellung einer abhängigen Beschäftigung der natürlichen Person im Einsatzbetrieb bietet; entscheidend ist nicht die formale Vertragslage, sondern die tatsächliche Tätigkeit im Betrieb des Auftraggebers.
Bei Nearshoring-Teams ohne Arbeitnehmerüberlassungserlaubnis droht zusätzlich die Fiktion eines Arbeitsverhältnisses direkt beim Kunden nach dem Arbeitnehmerüberlassungsgesetz. Wer ein polnisches oder serbisches Team als festen Bestandteil der eigenen Produktentwicklung führt, ohne die AÜG-Prüfung gemacht zu haben, haftet dafür als Entleiher. Die Bundesagentur für Arbeit hat zum 1. Oktober 2025 ihre Rechtsauffassung dahingehend präzisiert, dass reine Remote-Tätigkeiten ausschließlich aus dem Ausland nicht dem Erlaubnisvorbehalt des AÜG unterfallen - sobald das Team aber zum Onboarding oder zu Workshops nach Deutschland kommt, kann sich die Bewertung wieder drehen.
Unscharfe IP-Rechte und fehlende Open-Source-Compliance
Iterative Entwicklung erzeugt iteratives geistiges Eigentum. Wem gehört der Code nach Sprint 5? Darf die Agentur Komponenten aus einem früheren Projekt weiterverwenden? Was passiert mit Zwischenergebnissen, wenn das Projekt abgebrochen wird?
Ein sauberer Vertrag räumt dem Auftraggeber an allen ausgelieferten Sprint-Ergebnissen pauschal ausschließliche, zeitlich und räumlich unbegrenzte Nutzungsrechte einschließlich Bearbeitungsrecht ein (§§ 31, 34, 69c UrhG). Der Auftragnehmer behält sich seinerseits das Recht vor, eigene Frameworks und generische Module weiterzuverwenden - aber nur, wenn diese Grenze klar gezogen ist.
Noch größer ist das Risiko unkontrollierter Open-Source-Komponenten. Viele Codebases enthalten GPL- oder AGPL-Bausteine, ohne dass jemand das aktiv prüfen würde.
Das Landgericht München I hat in seiner Entscheidung vom 19. Mai 2004 (Az. 21 O 6123/04) bestätigt, dass die Lizenzbedingungen der GPL im deutschen Recht wirksam und durchsetzbar sind und ein Verstoß einen Unterlassungsanspruch nach § 97 UrhG begründet.
Für die Vertragsgestaltung bedeutet das: Der Auftragnehmer schuldet eine Software Bill of Materials (SBOM) pro Release, eine Compliance-Prüfung aller OSS-Komponenten und die Zusicherung, dass proprietäre Teile nicht mit inkompatiblen Lizenzen infiziert werden. Fehlt diese Klausel, haftet im Zweifel der Dienstleister - und der Kunde sitzt auf einer Software, die er unter Umständen selbst offenlegen müsste.
Fehlende Exit-, Transition- und Escrow-Regelung
Das letzte große Versäumnis betrifft das Projektende. Was passiert nach Sprint 40, wenn die Zusammenarbeit endet? Wer dokumentiert den Code? Wer schult das interne Team? Was passiert, wenn die Agentur insolvent wird und der Source-Code nur in deren GitLab liegt?
Ohne Exit-Regelung wird aus dem agilen Partner ein Vendor-Lock-in. Transition-Workshops werden zu spontanen Zusatzrechnungen, Dokumentation ist mündlich im Team und die Kontinuität steht und fällt mit dem Senior-Developer, der gerade den Job wechselt. Ein gut gebauter Rahmenvertrag regelt Transition-Pflichten als eigenen Leistungsgegenstand mit definiertem Stundenkontingent, schuldet maschinell prüfbare Dokumentation (Runbook, API-Docs, Architecture Decision Records) und sieht eine Source-Code-Hinterlegung bei einem Treuhänder vor, die bei Insolvenz, schweren Vertragsverstößen oder Non-Support freigegeben wird.
Sie planen ein agiles Projekt oder stecken in einem Konflikt? Wir prüfen Ihren Vertrag und zeigen Ihnen die stillen Bruchstellen.
Kostenlose Anfrage- Kostenlos beraten
- Kein Risiko, 100% vertraulich
Welche Folgen schlechte agile Verträge wirklich haben
Unscharfe agile Verträge kosten nicht nur Nerven. Sie erzeugen messbare Schäden auf drei Ebenen, die sich gegenseitig verstärken.
Operative Folgen: Projekt-Krise, Team-Burnout, Reputationsverlust
Der erste Schaden ist operativ. Festpreis-Projekte ohne Scope-Guard laufen nach Sprint 2 mit Verlust. Das Delivery-Team geht in den Crunch-Modus, Qualität sinkt, Fluktuation steigt. Auf Kundenseite rutscht der Go-Live-Termin, interne Roadmaps, die am Launch hängen (Marketing, Vertrieb, Kundenmigration), platzen. Product Owner und Fachbereich streiten mit dem Einkauf, die Sponsorin muss vor dem Vorstand Rede und Antwort stehen.
Beide Seiten verlieren Vertrauen und Handlungsfähigkeit. Die Folgen bleiben selten intern: Ehemalige Team-Mitglieder schreiben bei den einschlägigen Bewertungsportalen, Kunden sprechen in ihren Netzwerken, eine Key-Account-Beziehung bricht weg und ersetzt sich nicht einfach durch den nächsten Deal.
Finanzielle Folgen: Marge-Erosion, Doppelzahlungen, versunkene Investitionen
Auf Dienstleisterseite kippt die Projektmarge von geplanten 30 Prozent ins Minus, sobald mehrere Eskalationen parallel laufen. Nicht abgerechnete Change Requests werden zur stillen Verlustposition. Eine blockierte Abnahme bedeutet zwei Wochen keine Zahlung, was bei kleineren Agenturen ein Liquiditätsrisiko ist.
Auf Kundenseite wird versunken, was versunken ist: Sprint-Budget plus Nachbesserungs-Budget plus externer Rescue-Dienstleister, der den havarierten Code übernehmen muss. Dazu kommen Transition-Kosten, die nie budgetiert waren, und nicht selten Schadensersatzdrohungen, die zwar keine solide vertragliche Grundlage haben, aber als Verhandlungsmasse den Abwicklungsaufwand vervielfachen.
Juristische Folgen: DRV-Nachzahlung, AÜG-Fiktion, DSGVO-Bußgelder
Die teuersten Folgen sind die juristischen, weil sie lange nach Projektende zuschlagen und dann niemand mehr darauf vorbereitet ist.
- DRV-Statusfeststellung nach § 7a SGB IV – Bei scheinselbstständigen Freelancern können Beitragsnachzahlungen von vier Jahren rückwirkend, bei Vorsatz bis zu 30 Jahren, fällig werden.
- AÜG-Verstoß bei Nearshoring-Teams – Es droht die Fiktion eines Arbeitsverhältnisses direkt beim Kunden, inklusive Kündigungsschutz und Equal-Pay-Pflichten.
- DSGVO-Bußgelder bei Echtdaten in Staging – Wer Produktionsdaten ohne AVV und ohne Drittland-Prüfung in Sprint-Reviews oder Staging verarbeitet, riskiert Aufsichtsverfahren.
Jeder dieser drei Risiken wird im Tagesgeschäft einer agilen Auslieferung fast nie gesehen. Genau deshalb brauchen sie eine feste vertragliche Haltelinie.
Was ein rechtssicherer agiler Softwareentwicklungsvertrag regeln muss
Ein tragfähiger Vertrag für agile Entwicklung löst die oben beschriebenen Konfliktfelder nicht mit einem einzigen großen Text, sondern mit einem modularen Aufbau. Aus unserer Vertragspraxis haben sich folgende Bausteine als unverzichtbar erwiesen.
Rahmenvertrag plus Sprint-Statements-of-Work
Der Rahmenvertrag regelt alles, was pro Sprint nicht neu verhandelt werden soll: Rechtsnatur, Nutzungsrechte, Haftung, Vertraulichkeit, Kündigung, Exit, AVV, Compliance. Die Sprint-SoWs regeln pro Zyklus, was konkret geliefert wird, zu welchem Preis, mit welchen Akzeptanzkriterien und welcher Dauer. Dieser Aufbau passt zur Methode: der Rahmen steht, der Inhalt atmet mit dem Projekt.
Der Vorteil: Werkvertragliche Anforderungen lassen sich sauber an den Sprint-SoW knüpfen, ohne den Rahmenvertrag zu überladen. Änderungen erfolgen pro Sprint-Tranche in einem definierten Format, nicht über eine Kette von E-Mail-Anhängen.
Abnahme-Mechanik: Teilabnahme, DoD und die fiktive Abnahme vermeiden
Ein tragender Baustein ist ein klar beschriebenes Abnahme-Modell. Pro Sprint oder pro Release gibt es ein Abnahmeprotokoll mit Prüfkriterien (die vertragliche Definition of Done), eine Prüfungsfrist für den Kunden, eine Eskalationsmechanik bei Dissens und eine Teilabnahme-Regelung für funktional eigenständige Inkremente.
Gleichzeitig muss der Vertrag verhindern, dass ungewollt eine Abnahme eintritt. Wer die automatische Abnahmewirkung nach § 640 Abs. 2 BGB übersieht, verliert wichtige Mängelrechte - sei es, weil der Kunde auf eine Fertigstellungsanzeige schweigt, sei es, weil der Dienstleister die Abnahmefiktion bewusst provoziert. Eine saubere Vertragsklausel spricht dieses Risiko explizit aus und fixiert, wann und wie Schweigen Abnahme ist und wann nicht.
Change-Request-Prozess mit drei Kategorien
Eine der stillen Marge-Killer-Klauseln in Scrum-Verträgen ist die Change-Request-Mechanik. Ein brauchbarer Prozess unterscheidet mindestens drei Kategorien:
- Klarifikationen – Keine CR-Pflicht, werden aber dokumentiert und laufen im Klarifikations-Budget.
- Re-Priorisierung innerhalb des Scopes – CR-frei, solange die Gesamtkapazität der Sprint-Tranche nicht überschritten wird.
- Echte Scope-Erweiterungen – Schriftlicher CR-Antrag mit Aufwandsschätzung, schriftliche Beauftragung, dokumentierte Vergütungsanpassung.
Ein Klarifikations-Budget (z.B. 20 Prozent Overhead pro Sprint für Rücksprachen und Feintuning) macht diesen Prozess realitätstauglich, ohne dass jede Bagatelle zum CR wird. Genau in diesen Fällen setzen wir die Mechanik für beide Seiten auf, damit weder die Marge der Agentur noch das Budget des Kunden durch unauffällige Scope-Drift aufgefressen wird.
Vergütung und Preismodelle: Festpreis, Time-and-Material, Hybrid
Welches Preismodell passt, hängt von der Scope-Volatilität ab. Drei Grundformen dominieren die Praxis:
- Festpreis pro Sprint-Tranche (z.B. je zwei Sprints neu estimiert) kombiniert Budgetsicherheit mit agiler Anpassung.
- Time-and-Material mit Budget-Cap (Not-to-Exceed) schützt den Kunden vor überraschenden Kostenexplosionen und gibt der Agentur Kalkulationsspielraum.
- Hybrid-Modelle wie “Money for Nothing / Change for Free” erlauben beide Seiten, aus dem Vertrag auszusteigen oder Scope zu tauschen, ohne dass Strafzahlungen drohen.
Wichtig ist weniger das Label als die klare Zuordnung: Was ist Festpreis, was variabel, wo liegen die Cap-Grenzen, wer trägt das Überschreitungsrisiko, wann kommen welche Abschlagszahlungen?
Key-Person-Klauseln und Staffing-Contingency
Agile Teams stehen und fallen mit Schlüsselpersonen. Ein Senior-Developer oder erfahrener Product Owner ist nicht in zwei Wochen ersetzbar. Gleichzeitig ist 100-Prozent-Staffing-Stabilität utopisch - der Arbeitsmarkt liefert Fluktuation, Krankheit kommt vor.
Eine saubere Klausel benennt Key Roles namentlich, definiert einen Benachrichtigungs-Anspruch bei Wechsel (z.B. 30 Tage Vorlauf bei geplantem Rolltausch), regelt eine Onboarding-Zeit für Ersatzpersonen zu Lasten der Agentur und schafft Eskalationsmechaniken, wenn mehrere Key Persons in kurzer Zeit wechseln. Starre “Kein Austausch ohne Kundenzustimmung”-Klauseln sind in der Praxis wirkungslos, weil sie die Realität ignorieren.
IP, Open-Source-Compliance und Escrow
Der IP-Baustein räumt dem Auftraggeber pauschal ausschließliche, zeitlich und räumlich unbegrenzte Nutzungsrechte einschließlich Bearbeitungsrecht an allen ausgelieferten Sprint-Ergebnissen ein. Generische Frameworks und vorbestehende Module der Agentur bleiben in deren Eigentum, müssen aber dem Auftraggeber für die Nutzung der Gesamtlösung einfach und unbefristet lizenziert sein.
Die Open-Source-Compliance wird zur eigenständigen Pflicht: SBOM pro Release, Trennung kompatibler und inkompatibler Lizenzen, Gewährleistung für die richtige Zuordnung. Escrow-Klauseln hinterlegen den Source-Code bei einem Treuhänder und definieren Freigabetatbestände (Insolvenz, schwerer Vertragsbruch, Non-Support über definierten Zeitraum).
Datenschutz, AVV und Drittland-Transfer
Sobald Entwickler lesenden oder schreibenden Zugriff auf Kundendaten haben - auch auf einer Staging-Umgebung - ist ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO zwingend. Der Rahmenvertrag muss den AVV als Anlage führen, die technischen und organisatorischen Maßnahmen (TOM) beschreiben und eine Testdaten-Richtlinie verankern (im Zweifel: keine unveränderten Produktionsdaten in Dev/Staging, stattdessen Pseudonymisierung oder synthetische Daten).
Bei Nearshoring außerhalb der EU kommt die Drittland-Dimension hinzu.
Der Gerichtshof der Europäischen Union hat in seinem Urteil vom 16. Juli 2020 (Az. C-311/18, Schrems II) entschieden, dass eine Datenübermittlung auf Basis von Standardvertragsklauseln nur zulässig ist, wenn im Empfängerland ein gleichwertiges Schutzniveau besteht oder durch zusätzliche Schutzmaßnahmen hergestellt wird.
Für agile Teams in Drittländern heißt das: Standardvertragsklauseln (SCC) in der Modul-3-Variante für Subunternehmer, ergänzt um ein Transfer Impact Assessment und gegebenenfalls technische Schutzmaßnahmen wie Verschlüsselung oder Zugriffsbeschränkung. Fehlt diese Kette, steht die ganze Nearshoring-Konstruktion aufsichtsrechtlich auf Sand.
Wenn der Vertrag bereits im Streit steht: Unsere juristischen Hebel
Die meisten agilen Projektkonflikte erreichen uns nicht zur Vertragsgestaltung, sondern wenn es knirscht. Auch in der Eskalation gibt es klare Hebel, die rein operativ nicht greifbar sind.
Abnahme-Streit und Fiktionsgefahr
Wenn ein Sprint-Ergebnis abgelehnt wird oder der Kunde nach Fertigstellungsanzeige schweigt, droht die Auseinandersetzung um die Abnahme nach § 640 BGB. Wir dokumentieren Prüfungspflichten und Fristen, adressieren die Fiktionswirkung explizit und setzen gegebenenfalls eine Frist zur Erklärung. Auf Kundenseite verhindern wir, dass die Agentur einen unfertigen Stand über die Hintertür zur fiktiven Abnahme bringt. Auf Dienstleisterseite erzwingen wir eine Entscheidung des Kunden, damit die Zahlung nicht beliebig lange blockiert bleibt.
Gewährleistung, Mangel oder Change Request
Die zentrale Streitfrage nach Projektende lautet fast immer: Ist das, was der Kunde jetzt noch will, ein Mangel des ursprünglichen Werks oder eine nachträgliche Erweiterung? Die Beweislast liegt je nach Vertragstyp unterschiedlich. Wir prüfen die Sprint-Protokolle, Kick-Off-Dokumente, Backlog-Historien und ordnen jeden Einzelpunkt sauber zu. In 9 von 10 Fällen ist das juristische Ergebnis präzise das, was die Sprint-Dokumentation bereits nahelegt - nur muss diese Zuordnung jemand belastbar aufbereiten.
Der Bundesgerichtshof hat in seinem Urteil vom 5. Juni 2014 (Az. VII ZR 276/13) entschieden, dass der Besteller bei Softwaremängeln seiner Darlegungslast genügt, wenn er die beobachteten Mangelerscheinungen genau bezeichnet; er muss nicht zu den technischen Ursachen der Mangelerscheinung vortragen.
Diese Entscheidung ist für die Auftraggeberseite im Eskalationsfall entscheidend: Sie müssen nicht technisch erklären, warum eine Software falsch rechnet, Daten verliert oder sich nicht integrieren lässt - es reicht, die Fehlfunktion präzise zu beschreiben. Die Beweislast für die Fehlerfreiheit liegt nach Abnahme grundsätzlich bei Ihnen, aber der konkrete Zuschnitt der Darlegungslast ist durch diese Entscheidung deutlich praktikabler geworden.
Scheinselbstständigkeit und DRV-Prüfung
Wenn die Deutsche Rentenversicherung ein Statusfeststellungsverfahren einleitet, zählt jeder Tag. Wir prüfen die tatsächliche Ausgestaltung der Freelancer-Einbindung, identifizieren die kritischen Eingliederungsindizien und entwickeln eine Verteidigungslinie, die sowohl die vertraglichen als auch die gelebten Strukturen einbezieht. In vielen Fällen lässt sich durch zeitnahe Anpassungen und eine saubere Dokumentation auch rückwirkend das Bild glattziehen - vorausgesetzt, die Beratung beginnt früh.
Exit, Escrow und Source-Code-Herausgabe
Wenn ein Projekt beendet wird, ohne dass der Kunde funktionierenden Zugriff auf den Code hat, setzen wir die Herausgabe juristisch durch. Bei vorhandenem Escrow prüfen wir die Freigabetatbestände und die Rechte des Kunden gegenüber dem Treuhänder. Bei fehlendem Escrow nutzen wir die urheberrechtlichen Nutzungsrechte aus dem Vertrag und die werkvertragliche Herausgabepflicht als Druckmittel, damit der Kunde nicht auf einer nicht-wartbaren Black Box sitzen bleibt.
Vorsicht im Eskalationsfall
Jede E-Mail, jedes Kick-Off-Protokoll und jede Slack-Nachricht kann später zum Beweismittel werden. Wer mitten in einer Eskalation ohne juristische Begleitung kommuniziert, schwächt typischerweise seine eigene Position - unabhängig davon, ob er Recht hat.
Besonderheiten: Öffentliche Auftraggeber, Nearshoring und KI-Anteile
Drei Konstellationen verdienen besondere Aufmerksamkeit, weil sie über die Standard-Mechanik hinausgehen.
Öffentliche Auftraggeber und EVB-IT-Vertragsmuster
Nearshoring und Schrems-II-Folgen
Wir haben Schrems II oben schon angesprochen.
Agile Entwicklung mit KI-Anteilen
Zunehmend enthalten agile Projekte KI-Komponenten, sei es als integrierter Sprachassistent, als Scoring-Modul oder als Entwicklerwerkzeug (z.B. LLM-gestützte Code-Generierung).
Öffentliche Ausschreibung, Nearshoring oder KI-Anteile im Spiel? Wir strukturieren Ihren Vertrag so, dass er beide Dimensionen verträgt.
Kostenlose Anfrage- Kostenlos beraten
- Kein Risiko, 100% vertraulich
So arbeiten wir an agilen Softwareentwicklungsverträgen
Jede Beauftragung beginnt mit einer klaren Bestandsaufnahme - unabhängig davon, ob Sie neu gestalten oder einen bestehenden Vertrag im Konflikt prüfen lassen.
So läuft die Vertragsarbeit ab
- Kostenfrei
1. Ersteinschätzung
Wir sichten Rahmenvertrag, Sprint-SoWs, AVV und relevante Kommunikation und zeigen Ihnen die kritischen Bruchstellen.
-
2. Analyse und Strategie
Wir bewerten Rechtsnatur, Risiken und Handlungsoptionen und stimmen mit Ihnen das Ziel ab - Gestaltung, Nachverhandlung oder Eskalation.
-
3. Umsetzung
Wir gestalten den Vertrag neu, führen Nachverhandlungen mit der Gegenseite oder übernehmen die außergerichtliche und gerichtliche Durchsetzung.
-
4. Ergebnis
Sie erhalten einen tragfähigen Vertrag oder eine klare Lösung im Streit - mit dokumentierter Argumentation, auf die Sie auch in zwei Jahren noch zurückgreifen können.
Warum scheitern Eigenversuche so oft?
Viele unserer Mandanten berichten, dass sie zuerst versucht haben, den Vertrag intern zu gestalten oder einen bestehenden Streit im Direkt-Dialog zu klären. In der Mehrzahl der Fälle führt das zu zwei Problemen. Erstens werden die vertragstypischen Bruchstellen (Werkvertrag vs. Dienstvertrag, DoD vs. Abnahme, Change-Request-Kategorien) intern übersehen, weil Einkauf, Legal und Delivery je unterschiedliche Teilsichten haben. Zweitens wird in der Eskalation Kommunikation erzeugt, die später gegen den Verfasser steht - weil emotional formuliert, prozessual unscharf oder rechtlich angreifbar.
Wir arbeiten nicht bunter als Ihr internes Team. Wir arbeiten fokussierter, weil wir tausende Seiten agiler Verträge gesehen haben und die Muster erkennen, bevor sie sich in Ihrem konkreten Projekt wiederholen. Das spart Zeit in der Gestaltung und verhindert in der Eskalation die Fehler, die typischerweise den Prozess entscheiden.
| Kriterium | Eigenversuch | Mit unserer Kanzlei |
|---|---|---|
| Strukturtiefe | Oft Template-basiert, wenig sprintspezifisch | Modularer Rahmenvertrag mit passender Sprint-SoW-Logik |
| Rechtliche Abgrenzung | Werkvertrag vs. Dienstvertrag bleibt unscharf | Klare Rechtsnatur, verifiziert an der tatsächlichen Leistung |
| Change-Request-Prozess | Oft DIN-A4-Klausel, in der Praxis nicht tragfähig | Drei-Kategorien-Prozess mit Schwelle und Genehmigung |
| Scheinselbstständigkeit / AÜG | Nur oberflächlich im Blick, Eingliederung oft übersehen | Risikoprüfung vor Vertragsschluss und Handlungsanweisungen fürs Projekt |
| Eskalationsfähigkeit | Kommunikation oft selbst-kompromittierend | Dokumentation und Vorgehensweise auf späteren Prozess ausgerichtet |
Die Ersteinschätzung ist bei uns kostenfrei. Auf Basis Ihrer Unterlagen prüfen wir die Ausgangslage und unterbreiten Ihnen anschließend ein transparentes Angebot - mit klaren Leistungsbausteinen und ohne versteckte Stundensätze, damit Sie die Kostenseite planen können, bevor Sie uns mandatieren.
Nächste Schritte
Agile Softwareentwicklungsverträge sind kein Standard-Template und kein Template verkraftet die Realität des Projektalltags lange. Sie leben davon, dass Rechtsnatur, Scope-Mechanik, Abnahme, IP, Compliance und Exit als zusammenhängendes System gedacht werden. Wer diese Bausteine einzeln zusammensetzt, baut einen Vertrag, der in Sprint 1 gut aussieht und in Sprint 8 reißt.
Wir strukturieren agile Verträge gemeinsam mit Ihnen so, dass sie zur Methode und zur Realität Ihres Projekts passen - unabhängig davon, ob Sie auf Auftraggeber- oder Auftragnehmerseite stehen. Wenn ein Konflikt bereits läuft, bringen wir die Sprint-Historie, das Vertragswerk und die Kommunikation in eine Form, die sich juristisch halten lässt, und führen die Eskalation an Ihrer Seite.
In einem kostenfreien Erstgespräch prüfen wir Ihre Unterlagen, ordnen die Ausgangslage ein und zeigen Ihnen die nächsten sinnvollen Schritte. Auf dieser Basis entscheiden Sie, wie Sie weiter vorgehen wollen - wir liefern die Einordnung, Sie behalten die Kontrolle.