Vertragsgestaltung bei agiler Softwareentwicklung: Was Unternehmen wirklich regeln müssen

Zusammenfassung

• Agile Entwicklung verzichtet bewusst auf eine vollständige Leistungsbeschreibung zu Projektbeginn. Genau deshalb braucht sie einen Vertrag, der den dynamischen Leistungsgegenstand, die Vergütung und die Zusammenarbeit verbindlich einrahmt. Ohne diesen Rahmen entsteht das größte Risiko für den Auftraggeber: Er zahlt, ohne einen einklagbaren Erfolg zu haben.
• Der häufigste Streit im Krisenfall dreht sich um den Vertragstyp. Aus meiner Beratungspraxis lohnt sich hier eine klare Entscheidung schon im Vertrag: Die ausdrückliche Vereinbarung von Werkvertragsrecht vermeidet die spätere Diskussion und sichert dem Auftraggeber Gewährleistungsrechte.
• Die Leistungsbeschreibung wird nicht weggelassen, sondern verlagert. An die Stelle von Lasten- und Pflichtenheft treten Produktvision, Product Backlog und Sprint Backlogs, die im Vertrag als fortlaufend präzisierte Leistungsbeschreibung verankert werden.
• Teilabnahmen nach jedem Sprint und eine abschließende Endabnahme des Gesamtsystems sind das zentrale Steuerungsinstrument. Sie geben dem Auftraggeber Kontrolle und dem Auftragnehmer eine Abrechnungsgrundlage.
• Bei der Vergütung ist ein reiner Festpreis für das Gesamtprojekt unpassend. Eine Kombination aus aufwandsabhängiger Vergütung pro Sprint und einem erfolgsabhängigen Restanteil bringt die Interessen am ehesten in Ausgleich.
• Weitere kritische Punkte sind die vorzeitige Projektbeendigung, die Einräumung umfassender Nutzungsrechte am Quellcode samt Umgang mit Open Source und das oft unterschätzte arbeitsrechtliche Risiko einer verdeckten Arbeitnehmerüberlassung bei gemischten Teams.

1. Warum agile Projekte gerade einen guten Vertrag brauchen

Agile Softwareentwicklung beginnt mit einer bewussten Lücke. Zu Vertragsbeginn steht noch nicht fest, wie das fertige Produkt genau aussehen soll. Der Auftraggeber beschreibt zunächst nur, was er erreichen will, also seine Produktvision. Das konkrete Ergebnis bildet sich erst im Lauf der Entwicklung heraus. Bei Scrum, der bekanntesten agilen Methode, geschieht das in kurzen, gleich langen Zeitabschnitten, den Sprints, an deren Ende jeweils ein nutzbares Zwischenergebnis steht.

Daraus entsteht ein Missverständnis, das in der Praxis viele Projekte belastet: Weil die Methode flexibel ist, glauben die Beteiligten, der Vertrag dürfe ebenfalls vage bleiben. Das Gegenteil ist richtig. Wenn der Auftraggeber zu Beginn keinen festen Leistungsinhalt bestimmen kann, muss der Vertrag den Mechanismus regeln, mit dem die Leistung Schritt für Schritt konkretisiert wird. Fehlt dieser Mechanismus, droht eine reine Tätigkeitsbeziehung, in der der Auftraggeber zahlt, solange der Auftragnehmer arbeitet, und am Ende möglicherweise kein brauchbares Ergebnis und keine Mängelrechte hat. Solche Projekte schädigen beide Seiten, vor allem aber den Auftraggeber.

Hinzu kommt ein praktischer Befund, den viele aus eigener Erfahrung kennen: Die Erfolgsquote von IT-Projekten ist insgesamt niedrig, ein erheblicher Teil wird abgebrochen oder wird teurer und langsamer als geplant. Agile Methoden sind tendenziell krisenfester, weil sie früh Zwischenergebnisse liefern und Fehlentwicklungen sichtbar machen. Ein Allheilmittel gegen das Scheitern sind sie aber nicht. Der Vertrag muss deshalb für den Krisenfall ein belastbares Instrumentarium bereitstellen.

Merksatz: Agilität ersetzt nicht den Vertrag, sie verändert nur, was der Vertrag regeln muss. Statt eines fertigen Leistungskatalogs regelt er das Verfahren, mit dem die Leistung entsteht.

Ein verbreiteter Fehler verdient gleich zu Beginn einen Warnhinweis. Immer wieder starten Unternehmen Projekte auf Grundlage eines knappen Letter of Intent, einer Bestellung aus dem ERP-System oder eines formlosen Schreibens, in der Erwartung, der ausführliche Vertrag werde später noch unterschrieben. Häufig kommt es dazu nicht. Genau dieser Fall lag dem bislang einzigen veröffentlichten Gerichtsverfahren zur agilen Entwicklung zugrunde.

Achtung: Wer ein agiles Projekt ohne unterzeichneten Vertrag beginnt, trägt das volle Risiko der späteren Auslegung. Im Streit über Vergütung oder Mängel fehlt dann die Grundlage, und die Parteien streiten zusätzlich darüber, welches Recht überhaupt gilt.

2. Der zentrale Streitpunkt: Werkvertrag oder Dienstvertrag

a) Warum die Einordnung über Erfolg und Mängelrechte entscheidet

Die Frage nach dem Vertragstyp ist kein juristischer Selbstzweck. Sie entscheidet über zwei praktisch wichtige Dinge. Erstens hängt davon ab, ob dem Auftraggeber überhaupt Gewährleistungsrechte zustehen und welche. Werkvertragsrecht gewährt Nacherfüllung, Minderung, Rücktritt und Schadensersatz, weil der Auftragnehmer einen Erfolg schuldet. Dienstvertragsrecht kennt diese Mängelrechte nicht, weil dort nur die Tätigkeit als solche geschuldet ist. Zweitens richtet sich die Wirksamkeit vorformulierter Klauseln nach dem gesetzlichen Leitbild des jeweiligen Vertragstyps, was bei der AGB-Kontrolle Bedeutung gewinnt.

Die Interessen sind klar verteilt. Der Auftraggeber will Werkvertragsrecht, weil er am Ende eine funktionierende Software haben möchte und den Auftragnehmer in der Erfolgsverantwortung sehen will. Der Auftragnehmer neigt zum Dienstvertrag, weil er angesichts der starken Einbindung des Kunden und der zu Beginn unklaren Anforderungen keine Erfolgsverantwortung für etwas übernehmen möchte, das er noch nicht kennt.

b) Was die Rechtsprechung sagt

Höchstrichterlich ist die Frage für agile Projekte nicht geklärt. Für klassische IT-Projekte, also die Erstellung von Individualsoftware sowie die Anpassung und Implementierung von Standardsoftware mit gewissem Gewicht, ordnet der Bundesgerichtshof die Verträge in ständiger Rechtsprechung als Werkverträge ein.

Speziell zur agilen Methode gibt es bisher nur ein veröffentlichtes Verfahren. Das OLG Frankfurt am Main hat mit Urteil vom 17.08.2017 (Az. 5 U 152/16) über die Vergütung für die agile Erstellung einer Internetplattform nach Scrum entschieden. Es ließ die grundsätzliche Einordnung ausdrücklich offen und entschied den Fall anders: Selbst bei unterstellter Anwendbarkeit des Werkvertragsrechts hätte der Auftraggeber eine Frist zur Nacherfüllung setzen müssen, was er versäumt hatte. Die Vorinstanz, das LG Wiesbaden, hatte sich dagegen festgelegt und einen Werkvertrag bejaht. Sie begründete das damit, dass auch bei agiler Entwicklung im Kern die Konzeptionshoheit beim Auftraggeber und die Ausführungsverantwortung beim Auftragnehmer liege und der Auftraggeber im Ergebnis eine funktionierende Software erwarte.

c) Meine Empfehlung: Werkvertragsrecht ausdrücklich vereinbaren

In der Praxis sehe ich regelmäßig, dass Verträge die Typfrage offenlassen, weil beide Seiten den Streit scheuen. Das ist die schlechteste Lösung, denn sie verlagert die Auseinandersetzung in die Projektkrise, in der ohnehin schon Streit herrscht. Ich rate daher dazu, im Vertrag ausdrücklich die Anwendung von Werkvertragsrecht zu vereinbaren.

Dafür sprechen zwei Gründe. Zum einen steht diese Vereinbarung im Einklang mit den typischen Hauptleistungspflichten, weil am Ende eine lauffähige Software geschuldet ist. Gegen die Vereinbarung von Werkvertragsrecht bestehen deshalb keine durchgreifenden Wirksamkeitsbedenken. Die umgekehrte Wahl, also Dienstvertragsrecht trotz erfolgsbezogener Hauptleistungspflicht, ist dagegen problematisch und kann unwirksam sein, jedenfalls wenn das Entwicklungsteam ausschließlich vom Auftragnehmer gestellt wird. Zum anderen erlaubt gerade das Werkvertragsrecht Gestaltungen zugunsten des Auftragnehmers, etwa Teilabnahmen, die im Ergebnis beiden Seiten nützen.

Praxistipp: Bauen Sie die Typfrage stringent durch den ganzen Vertrag. Es genügt nicht, oben „Werkvertrag" zu schreiben. Leistungsbeschreibung, Abnahme, Vergütung und Mängelrechte müssen zum gewählten Typ passen. Eine Musterformulierung als Ausgangspunkt: „Auf dieses Vertragsverhältnis findet Werkvertragsrecht Anwendung. Der Auftragnehmer schuldet die Bereitstellung eines funktionierenden, abnahmefähigen Produkts nach Maßgabe der nachfolgenden Regelungen."

Ein Sonderfall verdient Aufmerksamkeit. In agilen Projekten ist es nicht unüblich, dass auch Mitarbeiter des Auftraggebers im Entwicklungsteam mitarbeiten. Dann übernimmt der Auftraggeber eine Mitverantwortung für den Erfolg, was die Werkvertragsvereinbarung angreifbarer macht. Solange die Beteiligten des Auftraggebers in der Minderzahl bleiben und im Wesentlichen beratend wirken, ohne die eigentliche Entwicklung zu leisten, bleibt die Vereinbarung von Werkvertragsrecht vertretbar. In solchen Konstellationen sollte der Vertrag ausdrücklich regeln, welche Partei die Hauptverantwortung für den Projekterfolg trägt.

3. Die kritischen Klauselthemen im Einzelnen

a) Leistungsbeschreibung: Produktvision, Product Backlog, Sprint Backlog

Im klassischen Wasserfallprojekt beschreibt der Auftraggeber seine Anforderungen vorab im Lastenheft, der Auftragnehmer antwortet mit dem Pflichtenheft, das die technische Umsetzung festlegt und zur vereinbarten Soll-Beschaffenheit wird. Diese beiden Dokumente sind nicht identisch, auch wenn sie in der Praxis oft verwechselt werden. Anhand des Pflichtenhefts lässt sich später ein Mangel feststellen, indem man Ist und Soll vergleicht.

Im agilen Projekt fällt diese vollständige Vorabbeschreibung weg. An ihre Stelle tritt ein dreistufiges System. Die Produktvision umschreibt die übergeordneten Ziele und sollte Vertragsbestandteil sein. Das Product Backlog listet die Einzelanforderungen, häufig als User Stories formuliert und nach Priorität geordnet. Es entspricht funktional dem Lastenheft, ist aber dynamisch und kann vom Auftraggeber jederzeit geändert werden, solange die betroffene Anforderung nicht gerade in einem Sprint bearbeitet wird. Das Sprint Backlog schließlich legt für den jeweiligen Sprint fest, wie die ausgewählten Anforderungen konkret umgesetzt werden, und übernimmt damit die Rolle des Pflichtenhefts.

Vertraglich muss dieser Mechanismus festgeschrieben werden, sonst bleibt unklar, was eigentlich geschuldet ist.

Praxistipp: Verankern Sie die Leistungsbeschreibung als lebendes Dokument. Eine bewährte Formulierung lautet sinngemäß: „Die Entwicklung erfolgt nach der als Anlage beigefügten Produktvision. Das Product Backlog stellt die durch die Sprint Backlogs fortlaufend präzisierte Leistungsbeschreibung dar. Widersprechen sich Sprint Backlogs, gehen die jüngeren den älteren vor."

b) Rollen und Mitwirkungspflichten des Auftraggebers

Agile Methoden kann der Auftragnehmer nicht allein anwenden. Sie verlangen die intensive und kontinuierliche Mitarbeit des Auftraggebers. Projekte, in denen nur der Dienstleister agil arbeitet und der Auftraggeber nicht mitzieht, scheitern nahezu zwangsläufig. Nach meiner Erfahrung ist die fehlende oder halbherzige Einbindung des Auftraggebers eine der häufigsten Ursachen für gescheiterte Projekte, noch vor rein technischen Problemen.

Der Vertrag sollte deshalb erstens die Projektmethodik ausdrücklich benennen, etwa Scrum, und auf eine im Internet verfügbare Beschreibung wie den Scrum Guide verweisen. Dieser Verweis allein genügt aber nicht, weil solche Beschreibungen Spielräume lassen. Diese Spielräume gehören in den Vertrag. Gerade bei Auftraggebern, die mit agilen Methoden wenig vertraut sind, hilft es, die zentralen Begriffe im Vertrag zu definieren und so eine Art Anleitung mitzuliefern.

Zweitens müssen die Rollen klar verteilt werden, insbesondere wer den Product Owner, den Scrum Master und das Entwicklungsteam stellt, und welche Aufgaben damit verbunden sind. Der Product Owner sollte aus dem Unternehmen des Auftraggebers kommen und für diese Aufgabe ausreichend freigestellt werden. Das ist ein praktischer Knackpunkt, denn häufig haben die Mitarbeiter des Auftraggebers neben dem Tagesgeschäft schlicht keine Zeit für das Projekt.

Cave: Lassen Sie die Definition of Done nicht allein vom Auftragnehmer formulieren. Dient sie zugleich als Abnahmekriterium, taugt sie nichts, wenn der Auftragnehmer den Maßstab selbst setzt. Der Auftraggeber, in der Regel über den Product Owner, sollte an der Definition of Done maßgeblich mitwirken.

Praxistipp: Regeln Sie die Mitwirkung messbar. Beispiele sind eine feste Reaktionszeit des Projektmanagers auf Rückfragen innerhalb definierter Geschäftszeiten, die ausdrückliche Freistellung des Product Owners und die Folge bei Verstößen, etwa eine Verschiebung des Zeitplans um den Verzögerungszeitraum.

c) Änderungen statt Change Request

Im Wasserfallprojekt werden die Anforderungen zu Beginn festgeschrieben, und jeder spätere Änderungswunsch läuft über ein Change-Request-Verfahren, das gesondert beauftragt und vergütet wird. Daran knüpft der typische Streit an, ob eine Funktion bereits geschuldet war oder eine zusätzliche Leistung darstellt.

Agile Projekte kehren dieses Verhältnis bewusst um. Änderungen der Anforderungen sind ausdrücklich willkommen, auch spät im Projekt. Ein klassisches Change-Request-Verfahren passt deshalb nicht. Das bedeutet aber nicht, dass jede Erweiterung kostenlos und im ursprünglichen Zeitrahmen umzusetzen wäre. Vielmehr gilt im Regelfall, dass Änderungen keiner gesonderten Vertragsergänzung bedürfen, eine Anpassung von Vergütung oder Zeitplan aber dann erforderlich wird, wenn sich die Änderung auf Aufwand und Kosten auswirkt.

Praxistipp: Stellen Sie im Vertrag klar, dass das Product Backlog außerhalb des laufenden Sprints geändert, ersetzt oder neu priorisiert werden darf. Ergänzen Sie eine Hinweis- und Freigaberegel sinngemäß: „Wirken sich Änderungen auf die Zeit-, Aufwands- und Kostenschätzung aus, weist der Auftragnehmer unverzüglich in Textform darauf hin. Der Auftragnehmer setzt diese Anforderungen erst nach Freigabe durch den Auftraggeber in Textform um."

d) Abnahme: Teilabnahmen plus Endabnahme

Die Abnahme ist im Werkvertrag das Scharnier, das Fälligkeit und Gewährleistung auslöst. Agile Projekte liefern früh nutzbare Softwareteile. Das spricht dafür, nach jedem Sprint eine Teilabnahme des jeweiligen Increments vorzusehen, gemessen an der Definition of Done. Teilabnahmen geben dem Auftraggeber laufende Kontrolle und dem Auftragnehmer eine regelmäßige Abrechnungs- und Sicherungsgrundlage.

Trotz Teilabnahmen bleibt eine Endabnahme des Gesamtsystems unverzichtbar. Die einzelnen Teile müssen nicht nur für sich, sondern auch im Zusammenspiel funktionieren. Die Endabnahme betrifft daher die integrativen Bestandteile und die Leistungsfähigkeit des Gesamtprodukts, während die bereits erfolgten Teilabnahmen unberührt bleiben.

Praxistipp: Sichern Sie die Abnahme zeitlich ab. Bewährt hat sich eine Prüffrist von einigen Werktagen und eine Abnahmefiktion, etwa: „Jedes Product Increment gilt als abgenommen, wenn der Auftraggeber nicht innerhalb von zehn Tagen nach Aufforderung in Textform Mängel meldet." Eine Übernahme in den Produktivbetrieb sollte ebenfalls als Teilabnahme gelten. Wegen unwesentlicher Mängel darf die Abnahme nicht verweigert werden.

e) Vergütung: weg vom Festpreis, hin zum Kombimodell

Bei der Vergütung sind die Interessen gegenläufig. Der Auftraggeber wünscht Planungssicherheit und tendiert zum Festpreis mit Obergrenze, der Auftragnehmer zur reinen Abrechnung nach Aufwand. Eine Seite setzt sich selten vollständig durch: Fordert der Auftraggeber einen Maximalpreis, kalkuliert der Auftragnehmer einen Puffer ein. Verlangt der Auftragnehmer reine Aufwandsvergütung, fordert der Auftraggeber eine detaillierte Schätzung, die einem Festpreis nahekommt.

Von einem Festpreis für das Gesamtprojekt rate ich im agilen Kontext ab. Der Aufwand lässt sich zu Beginn kaum seriös schätzen, und die Festpreislogik widerspricht der Idee, Anforderungen unterwegs zu ändern. Eine reine Aufwandsvergütung ist für den Auftragnehmer risikolos, birgt aber die Gefahr, dass auch Mängelbeseitigung in Rechnung gestellt wird, die eigentlich unentgeltlich geschuldet ist.

Am ehesten interessengerecht ist eine Kombination aus aufwandsabhängiger und erfolgsabhängiger Vergütung. Ein praktikables Modell zahlt pro Sprint einen festen Betrag, unabhängig davon, ob am Sprintende eine Teilabnahme erfolgt, und schüttet einen Restbetrag erst mit der Endabnahme aus. Dass die Sprint-Vergütung nicht von der Teilabnahme abhängt, nimmt dem Auftraggeber den Anreiz, Abnahmen grundlos zu verweigern. Ergänzend kann ein Sicherheits- und Motivationsmodell vorsehen, dass pro Sprint nur ein Teil, etwa achtzig Prozent, abgerechnet wird und der Rest nach Endabnahme folgt.

Cave: Mängelbeseitigung darf nicht über die Aufwandsabrechnung mitvergütet werden. Regeln Sie ausdrücklich, dass Aufwände für die Beseitigung von Mängeln aus früheren Sprints separat zu erfassen, dem Auftraggeber vorzulegen und nicht zu berechnen sind. Eine Abrechnung nach Aufwand steht der Einordnung als Werkvertrag im Übrigen nicht entgegen.

Eine Vergütung nach Meilensteinen passt nur, wenn die Leistungspakete schon zu Beginn feststehen, was im agilen Projekt typischerweise nicht der Fall ist. Eine Ausnahme bildet die Einführung modularer Standardsoftware, bei der von Anfang an klar ist, welche Module umgesetzt werden.

f) Vorzeitige Beendigung als geplante Sollbruchstelle

Weil beide Seiten zu Beginn oft keine genaue Vorstellung vom Ergebnis haben, ist die Gefahr größer als im klassischen Projekt, dass sich die Vorstellungen unterwegs als unvereinbar erweisen. Der Vertrag sollte deshalb einen geordneten Ausstieg ermöglichen, der für beide Seiten tragbar ist.

Sinnvoll ist eine kurze Kündigungsmöglichkeit zum Ende eines Sprints, ergänzt um das Recht zur außerordentlichen Kündigung. Daneben lässt sich das Kündigungsrecht des Auftraggebers aus § 648 BGB modifizieren und nach dem Projektstadium differenzieren, sodass ein früher Ausstieg anders behandelt wird als ein später. Da im agilen Projekt auch der Auftragnehmer ein Interesse an einer vorzeitigen Beendigung haben kann, etwa bei schlechter Zusammenarbeit unterhalb der Schwelle der außerordentlichen Kündigung, bietet sich eine gemeinsame Projektevaluierung als geplante Sollbruchstelle an.

Praxistipp: Sehen Sie nach den ersten Sprints eine gemeinsame Evaluierung vor. Jede Partei kann dort entscheiden, das Projekt abzubrechen oder die Fortsetzung von geänderten Bedingungen abhängig zu machen. Regeln Sie zugleich die Vergütungsfolge, etwa volle Vergütung der erbrachten Leistungen bei Abbruch durch den Auftraggeber und einen Abschlag, wenn der Auftragnehmer abbricht.

Aus meiner Beratungspraxis hat das Vorverlagern der Zahlungsflüsse einen unterschätzten Nebeneffekt. Wenn im laufenden Projekt bereits Teilzahlungen geflossen sind, einigen sich die Parteien im Streitfall sehr viel leichter und trennen sich, ohne dass weitere Zahlungen nötig werden. Schwieriger ist die Lage, wenn über Monate gearbeitet wurde, aber noch keine einzige Zahlung erfolgt ist.

g) Mängelrechte über mehrere Sprints

Eine Besonderheit ergibt sich daraus, dass jedes Increment auf den vorherigen aufbaut und ständig weiterentwickelt wird. Ein in einem frühen Sprint als Mangel erscheinendes Defizit kann später bedeutungslos werden, wenn die betreffende Anforderung einvernehmlich aufgegeben wird. Es bietet sich daher an, zu vereinbaren, dass Mängel im jeweils folgenden Sprint behoben werden und die eigentliche Gewährleistungsfrist erst mit der Endabnahme beginnt. Gewährleistungsrelevant sind dann nur Anforderungen, die am Ende noch vorgesehen waren. Sollen einzelne Increments schon produktiv genutzt werden, kann alternativ die Gewährleistung bereits mit der jeweiligen Teilabnahme beginnen.

4. Weitere kritische Punkte, die oft vergessen werden

a) Nutzungsrechte am Quellcode und Open Source

Der Auftraggeber bezahlt die Entwicklung und will das Ergebnis frei verwerten und weiterentwickeln können, auch durch andere Dienstleister. Das setzt voraus, dass ihm umfassende Nutzungsrechte eingeräumt werden. Diese Rechte sollten im Vertrag genau beschrieben werden, damit keine Auslegungszweifel entstehen und nicht über die sogenannte Zweckübertragungsregel des § 31 Abs. 5 UrhG am Ende weniger übertragen wird als gewollt. Sinnvoll ist die Einräumung eines ausschließlichen, räumlich, zeitlich und inhaltlich unbeschränkten, übertragbaren Nutzungsrechts für alle bekannten und künftigen Nutzungsarten, einschließlich des Rechts zur Bearbeitung und Weiterentwicklung. Da Urheberrechte selbst nicht übertragbar sind, wird der notwendige Umfang über eine umfassende Nutzungsrechtseinräumung erreicht.

Ein praktischer Punkt, der im Vertrag oft fehlt, ist der Zugang zum Quellcode während und nach dem Projekt. Aus meiner Beratungspraxis ist es ratsam, den Auftragnehmer zu verpflichten, gut lesbaren, dokumentierten Code zu liefern und ihn laufend auf einer vom Auftraggeber bereitgestellten Umgebung abzulegen. Andernfalls steht der Auftraggeber bei einem Dienstleisterwechsel vor einem schwer wartbaren Ergebnis.

Cave: Open-Source-Komponenten können über sogenannte Copyleft-Effekte dazu führen, dass deren Lizenzbedingungen auf die eigene Software durchschlagen. Will der Auftraggeber das vermeiden, sollte der Vertrag den Einsatz von Open Source entweder ausschließen oder zumindest eine Offenlegungspflicht des Auftragnehmers vorsehen, welche Komponenten verwendet werden und wie sie eingebunden sind.

b) Risiko der verdeckten Arbeitnehmerüberlassung

Das in der Praxis am häufigsten unterschätzte Risiko liegt nicht im Vertragsrecht, sondern im Arbeitsrecht. Agile Methoden leben von gemischten Teams, die eng zusammenarbeiten, sich täglich abstimmen und gemeinsam am selben Ort entwickeln. Genau diese enge Einbindung externer Mitarbeiter in die Organisation des Auftraggebers kann die Grenze zur Arbeitnehmerüberlassung überschreiten. Wird das Personal des Dienstleisters faktisch wie eigenes Personal eingesetzt und in die Weisungsstrukturen des Auftraggebers integriert, droht eine ungewollte, weil nicht erlaubte Arbeitnehmerüberlassung mit erheblichen Folgen, bis hin zur Fiktion eines Arbeitsverhältnisses und zu Bußgeldern.

Dieses Thema gehört bereits in die Vertragsgestaltung und in die Schulung der Projektbeteiligten. Der Vertrag sollte die Selbstständigkeit des Auftragnehmers und die Weisungsfreiheit des Entwicklungsteams klar abbilden. Soll Werkvertragsrecht gelten, ist außerdem darauf zu achten, dass das Entwicklungsteam grundsätzlich aus Mitarbeitern des Auftragnehmers besteht und Mitarbeiter des Auftraggebers nur solche Aufgaben übernehmen, die ohnehin zur allgemeinen Mitwirkung zählen, etwa das Bereitstellen von Informationen.

Achtung: Wer externe Entwickler dauerhaft in die eigenen Teams, Räume und Weisungswege integriert, riskiert eine verdeckte Arbeitnehmerüberlassung. Die Rolle des Product Owner beim Auftraggeber und die Weisungsfreiheit des Entwicklungsteams sollten im Vertrag und im gelebten Projektalltag konsequent getrennt geführt werden.

c) Eskalation und Streitbeilegung

Weil agile Projekte von enger Zusammenarbeit leben, brauchen sie auch einen geordneten Weg für Konflikte. Bewährt hat sich ein Steuerungs- oder Lenkungsausschuss mit entscheidungsbefugten Vertretern beider Parteien, der Streitfragen vor der Eskalation auffängt und Entscheidungen dokumentiert. Daneben gehören in den Schlussteil des Vertrags üblicherweise eine Abwehrklausel gegen entgegenstehende Geschäftsbedingungen, eine Regelung zum Gerichtsstand und gegebenenfalls eine Schiedsabrede.

Merksatz: Der gute agile Vertrag ist kein Korsett, das die Flexibilität erstickt, sondern ein Geländer. Er hält das Verfahren stabil, ohne den Inhalt der Software vorwegzunehmen.

5. Checkliste für den agilen Softwarevertrag

Die folgende Liste fasst die Punkte zusammen, die in keinem agilen Projektvertrag fehlen sollten.

• Projektmethodik ausdrücklich benannt und durch eine eigene Beschreibung im Vertrag ergänzt, nicht nur per Verweis auf den Scrum Guide.
• Vertragstyp festgelegt, Empfehlung: ausdrückliche Vereinbarung von Werkvertragsrecht, stringent durch den ganzen Vertrag durchgezogen.
• Produktvision als Anlage, Product Backlog und Sprint Backlogs als fortlaufend präzisierte Leistungsbeschreibung verankert.
• Rollen verteilt: Product Owner beim Auftraggeber, ausreichend freigestellt, mit klar beschriebenen Aufgaben.
• Mitwirkungspflichten messbar geregelt, mit Reaktionszeiten und Folgen bei Verstößen.
• Definition of Done unter maßgeblicher Mitwirkung des Auftraggebers.
• Änderungsmechanismus statt Change Request, mit Hinweis- und Freigabepflicht bei Auswirkungen auf Aufwand und Kosten.
• Teilabnahmen nach jedem Sprint plus Endabnahme des Gesamtsystems, mit Prüffrist und Abnahmefiktion.
• Vergütungsmodell, Empfehlung: Kombination aus Sprint-Vergütung und erfolgsabhängigem Restanteil, kein Gesamtfestpreis.
• Klarstellung, dass Mängelbeseitigung nicht gesondert vergütet wird.
• Regelung zur vorzeitigen Beendigung, idealerweise mit gemeinsamer Projektevaluierung als Sollbruchstelle.
• Umfassende Nutzungsrechte am Produkt und Quellcode, Zugang zum Code, Umgang mit Open Source.
• Arbeitsrechtliche Absicherung gegen verdeckte Arbeitnehmerüberlassung.
• Eskalationsmechanismus, Gerichtsstand, Abwehrklausel.

6. Typische Fallstricke

• Projektstart ohne unterzeichneten Vertrag. Der ausführliche Vertrag wird auf später verschoben und nie geschlossen. Im Streit fehlt dann die Grundlage.
• Agilität als Ausrede. Nach dem Scheitern wird fehlende Organisation oder mangelhafte Software mit einem angeblich agilen Vorgehen erklärt, obwohl die Methode nie wirksam vereinbart oder gelebt wurde.
• Nicht freigestellter Product Owner. Die Schlüsselrolle beim Auftraggeber wird neben dem Tagesgeschäft mitgemacht, Anforderungen und Rückfragen bleiben liegen, das Projekt stockt.
• Gesamtfestpreis trotz unklarer Anforderungen. Die Kalkulation kann nicht aufgehen, es folgt entweder ein hoher Pufferaufschlag oder Streit über Mehraufwand.
• Gemischte Teams ohne arbeitsrechtliche Absicherung. Die enge Zusammenarbeit kippt unbemerkt in eine verdeckte Arbeitnehmerüberlassung.

7. Häufige Fragen aus der Praxis

Brauchen wir überhaupt einen ausführlichen Vertrag, wenn wir agil arbeiten? Ja, gerade dann. Agile Methoden verzichten bewusst auf eine vollständige Leistungsbeschreibung zu Beginn. Der Vertrag muss deshalb das Verfahren regeln, mit dem die Leistung Schritt für Schritt entsteht, sowie Abnahme, Vergütung, Mitwirkung und Beendigung. Ohne diesen Rahmen trägt vor allem der Auftraggeber das Risiko.

Sollen wir Werkvertrag oder Dienstvertrag vereinbaren? Aus Auftraggebersicht ist die ausdrückliche Vereinbarung von Werkvertragsrecht zu empfehlen. Sie sichert Mängelrechte, steht im Einklang mit dem Ziel einer funktionierenden Software und vermeidet den Streit über den Vertragstyp in der Projektkrise. Wichtig ist, dass der gesamte Vertrag konsequent zu dieser Wahl passt.

Wie beschreiben wir die Leistung, wenn am Anfang noch nicht klar ist, was herauskommt? Über drei Stufen. Die Produktvision umreißt das Ziel und wird Vertragsbestandteil. Das Product Backlog listet und priorisiert die Anforderungen. Die Sprint Backlogs konkretisieren sie laufend. Im Vertrag wird festgehalten, dass diese Dokumente zusammen die fortlaufend präzisierte Leistungsbeschreibung bilden.

Was passiert mit Änderungswünschen während des Projekts? Im agilen Projekt sind Änderungen außerhalb des laufenden Sprints grundsätzlich willkommen und brauchen kein förmliches Change-Request-Verfahren. Eine Anpassung von Vergütung oder Zeitplan ist nur nötig, wenn sich die Änderung auf Aufwand und Kosten auswirkt. Der Auftragnehmer muss darauf hinweisen, der Auftraggeber gibt frei.

Wie sollten wir die Vergütung gestalten? Nicht als Gesamtfestpreis. Empfehlenswert ist eine Kombination aus einer Vergütung pro Sprint und einem erfolgsabhängigen Restanteil nach Endabnahme. Mängelbeseitigung sollte ausdrücklich von der Abrechnung ausgenommen werden.

Wann beginnt die Gewährleistung bei vielen aufeinander aufbauenden Sprints? Sinnvoll ist häufig, Mängel im jeweils folgenden Sprint zu beheben und die Gewährleistungsfrist erst mit der Endabnahme beginnen zu lassen. Sollen einzelne Teile schon produktiv genutzt werden, kann die Gewährleistung auch mit der jeweiligen Teilabnahme starten.

Können wir das Projekt vorzeitig beenden, wenn es nicht läuft? Ja, wenn der Vertrag es vorsieht. Bewährt sind eine kurze Kündigung zum Sprintende, ein modifiziertes Kündigungsrecht des Auftraggebers und eine gemeinsame Evaluierung nach den ersten Sprints, in der beide Seiten aussteigen oder die Bedingungen nachverhandeln können. Geregelt werden sollte jeweils die Vergütungsfolge.

Wem gehört am Ende der Code? Dem Auftraggeber sollten umfassende, ausschließliche Nutzungsrechte am Produkt und am Quellcode eingeräumt werden, einschließlich des Rechts zur Weiterentwicklung. Sichern Sie zusätzlich den laufenden Zugang zum Code und regeln Sie den Umgang mit Open-Source-Komponenten.

Ist Scrum arbeitsrechtlich ein Problem? Es kann eines werden. Die enge Einbindung externer Entwickler in die Organisation des Auftraggebers kann in eine verdeckte Arbeitnehmerüberlassung kippen. Achten Sie auf die Weisungsfreiheit des Entwicklungsteams, auf eine saubere Rollentrennung und auf entsprechende Schulung der Beteiligten.