Agile Softwareentwicklung: Vertragsgestaltung und Praxistipps

Agile Softwareentwicklung (z.B. nach Scrum oder Kanban) hat das statische Wasserfallmodell vielerorts abgelöst. Die Flexibilität agiler Projekte erfordert jedoch einen belastbaren vertraglichen Rahmen. Sonst sind rechtliche Konflikte zwischen Entwickler und Auftraggeber vorprogrammiert.

Klassische Programmierung nach dem Wasserfallmodell

Bei den klassischen Programmiermethoden zur Entwicklung einer Softwarelösung nach dem Wasserfallmodell ist das Projekt in aufeinanderfolgende Phasen organisiert.

Die Ergebnisse der einzelnen Phasen gehen – wie bei einem Wasserfall – immer als Vorgaben in die nächstfolgende Phase ein. Jede Aktivität muss vollständig durchgeführt werden, bevor die nächste beginnen darf. Rückschritte kann es nur zur unmittelbar vorangegangenen Phase geben.

Charakteristisch für Programmierung nach dem Wasserfallmodell ist, dass die Beteiligung der Anwender nur in der Anforderungsanalysephase vorgesehen ist. Die Anforderungen an das Produkt werden schon vor Beginn der Entwicklung durch den Auftraggeber in einem sog. Lastenheft festgelegt. Im Lastenheft werden alle Anforderungen des Auftraggebers an die Lieferungen und Leistungen des Auftragnehmers festgehalten.

Nach oben

Agile Softwareentwicklung

Ändern sich die Anforderungen an das Softwareprojekt, können klassische Modelle meist nur träge reagieren. Rücksprünge und das erneute Durchlaufen von Projektphasen kosten Zeit und Geld. Gerade bei Neuentwicklungen sind unklare oder sich häufig ändernde Anforderungen aber eher die Regel als die Ausnahme.

Bei komplexen Entwicklungen geht man daher dazu über, die vorgeschaltete Planungsphase deutlich zu reduzieren und die Ziele erst im laufenden Prozess festzulegen. Die bekannteste dieser agilen Methoden heißt Scrum. Der Begriff Scrum ist angelehnt an das vom Schiedsrichter angeordnete Gedränge beim Rugby.

Nach der Grundidee von Scrum sind drei verschiedene “Rollen” auszufüllen:

• Der Scrum Master übernimmt vor allem Koordinationsaufgaben. Er sorgt dafür, dass der Scrum Prozess eingehalten wird, löst Konflikte und moderiert die Scrum Meetings. Der Scrum Master hat in der Regel keine Weisungsbefugnis gegenüber den Teammitgliedern. Seine Rolle besteht vorwiegend darin, für optimale Arbeitsbedingungen und Abläufe im Scrum Team zu sorgen.
• Der Product Owner ist der Produktverantwortliche. Er pflegt das Product Backlog, eine Liste, in der die Anforderungen an ein Produkt priorisiert dokumentiert werden. Darüber hinaus besetzt er die wichtigen Schnittstellen zu Stakeholdern und Management. Typischerweise gehört der Product Owner zum Lager der Auftragnehmerseite. Dies ist allerdings nicht zwingend. Es kann auch vereinbart werden, dass ein Mitarbeiter des Auftraggebers die Position des Product Owners ausfüllt.
• Das Scrum Team sorgt dafür, dass die im Product Backlog niedergelegten Anforderungen erfüllt werden. Das Team organisiert sich selbst. Das heißt, es entscheidet selbstständig darüber, wie es die Anforderungen aus dem Backlog umsetzt.

Nach oben

Wann ist agiles Vorgehen (nach Scrum) sinnvoll?

Nicht übersehen werden darf, dass Scrum letztlich auch eine Philosophie ist, auf die man sich einlassen muss.

Nach oben

Vertragstyp: Werkvertrag, Dienstvertrag oder etwas anderes?

Gerade bei agilen Projekten, die sich durch Flexibilität in der Vorgehensweise auszeichnen, kann es zu Missverständnissen über die Rechte und Pflichten der Parteien kommen. Diesem Risiko sollte durch eine klare Vertragsgrundlage entgegengewirkt werden.

Es gibt keinen Vertragstyp, der pauschal auf alle Arten von agilen Projekten passt. In Betracht kommt sowohl Werkvertragsrecht, bei dem ein konkreter Erfolg geschuldet ist (= lauffähige Software), als auch Dienstvertragsrecht, bei dem die geschuldete Leistung in der Erbringung von Diensten liegt, ohne dass ein konkreter Erfolg geschuldet wird (= Programmieren).

Indizien pro Dienstvertrag

• starke Einbindung des Auftraggebers im gesamten Prozess
• keine klaren Vorgaben über die fertige Software
• Weisungen durch den Auftraggeber im Verlauf der Entwicklung
• Vertragsgegenstand (und damit Auslöser der Vergütungspflicht) ist die Programmierleistung, nicht die fertige Software

Indizien pro Werkvertrag

• Einbindung des Auftraggebers hauptsächlich vor Start der Programmierarbeiten
• Klare Darlegung des Vertragsgegenstandes, etwa in Lasten- bzw. Pflichtenheften
• Vertragsgegenstand (und damit Auslöser der Vergütungspflicht) ist nicht die Programmierleistung, sondern die fertige Software
• Keine Weisungsbefugnis des Auftraggebers während des laufenden Projekts

Rechtsprechung zur Einordnung des Vertragstyps bei agilen Projekten ist bislang noch dünn gesät.

Eine Klage vor dem Landgericht Wiesbaden auf “Bezahlung” eines Softwareprojekts (150.000 Euro) wurde abgewiesen, weil das Gericht den Scrum Vertrag als Werkvertrag einstufte. Da die bisher geleistete Arbeit für den Auftraggeber unbrauchbar war, schuldete er aus Sicht des Gerichts keinen Werklohn (LG Wiesbaden, Urteil vom 30.11.2016, Az. 11 O 10/15).

Das OLG Frankfurt hob die Entscheidung in der Berufungsinstanz auf und sprach die Vergütung zu (OLG Frankfurt, Urteil vom 17.08.2017, Az. 5 U 152/16). Ob Werk- oder Dienstvertragsrecht anzuwenden sei, ließ das Gericht offen. Die Vergütung sei in jedem Fall geschuldet gewesen, weil die Parteien im Laufe des Projekts einen Ratenzahlungsvertrag geschlossen hatten. Daraus folgerte das Oberlandesgericht, dass sich die Parteien zumindest zu diesem Zeitpunkt einig waren, dass die bis dahin erbrachten Programmierleistungen vom Auftraggeber als grundsätzlich vertragsgemäß und der Zahlungsanspruch als fällig anerkannt worden waren.

Obwohl das Oberlandesgericht in seinem Urteil ausführlich zur Anwendung von Werkvertragsrecht bei Scrum Stellung nimmt, lassen sich aus der Entscheidung nur bedingt allgemeine Rückschlüsse ableiten. Hiervor warnt auch Rechtsanwalt Christian Welkenbach in CR 2017, 639 ff. “Scrum auf dem Prüfstand der Rechtsprechung – Lehren für die Vertragsgestaltung”.

Das Gericht lässt nämlich offen, ob Werk- oder Dienstvertragsrecht anzuwenden ist. Vielmehr stellt es fest, dass im verhandelten Fall sowohl die Anwendung von Dienst- als auch die Anwendung von Werkvertragsrecht zu einer Vergütungspflicht führt. Zweitens gab es im Prozess die Besonderheit einer Ratenzahlungsvereinbarung im Verlauf der Zusammenarbeit, auf die das Gericht ebenfalls wesentliche Teile seines Ergebnisses stützt. Drittens war das Projekt noch nicht abgeschlossen, so dass sich das Gericht nur dazu äußerte, was im Zeitpunkt des Projektabbruchs geschuldet war, nicht aber, wie die am Ende vertragsgemäße Leistung ausgesehen hätte.

Festgehalten werden kann aber, dass das Gericht in dem Umstand, dass bei Scrum noch nicht von vornherein feststeht, wie das das Endprodukt auszusehen hat, kein Hindernis für die Annahme von Werkvertragsrecht sieht. Insoweit komme es auch in Betracht (deutlicher wird das Gericht leider nicht), in der jeweiligen Fortführung des Projekts nach den sprint reviews und den damit einhergehenden Zahlungen eine Abnahme des bisher Geleisteten – und nicht lediglich eine Abschlagszahlung – zu sehen.

Zweitens berücksichtigte das Gericht die agile Methodik auch bei der Frage der geschuldeten Dokumentationspflichten: Hinsichtlich der Systemarchitektur und ihrer Komponenten sah das Gericht eine Dokumentation, deren Brauchbarkeit von der Beratung des früheren Entwicklerteams abhängt, als hinreichend an. Begründet wurde dies damit, dass das Projekt zum Zeitpunkt des Abbruchs auf weitere Kooperation, insbesondere weitere Beratung durch den Auftragnehmer ausgelegt war. Entsprechend habe die zu diesem Zeitpunkt geleistete Dokumentation der Systemarchitektur und der Komponenten dem vertraglich Geschuldeten entsprochen.

Hinsichtlich des Quellcodes sah das Gericht in dem Umstand, dass dieser zwar “durchweg […] wenn auch […] nur sehr rudimentär […] und fachlich nicht überall als ausreichend zum Verständnis” kommentiert war, keinen erheblichen Mangel.

Diese beiden Punkte zeigen, dass den Parteien bei der Ausgestaltung und praktischen Umsetzung des Softwareprojekts viele Freiheiten bleiben. Die Kehrseite dieser Freiheiten liegt darin, dass vertraglich fixiert werden muss, wie das Softwareprojekt gelebt werden soll. Andernfalls besteht die Gefahr, dass ein Gericht die Lücken füllt und es dabei zu Überraschungen kommt.

Nach oben

Tipps zur Vertragsgestaltung

Bei Beginn eines agilen Projekts ist der Leistungsgegenstand nicht konkret festgelegt. Zu diesem Zeitpunkt existiert meist nur eine Vision, die noch nicht die gesamten Anforderungen des Produkts umfasst. Eine Festlegung von bestimmten Meilensteinen, Teilergebnissen oder sogar der Software im Ganzen wäre mit den Grundsätzen agiler Entwicklung demnach nicht vereinbar. Allerdings können gewisse Punkte vorab in einem Rahmenvertrag festgelegt werden.

Oft wird dazu geraten, im ersten Schritt einen Rahmenvertrag abzuschließen, der die dienstvertraglichen Elemente der Zusammenarbeit umfasst. Daneben sollen die einzelnen Sprints als Teilprojektverträge den werkvertraglichen Teil erfassen. Das ist ein guter Ansatz, aber keine Garantie dafür, dass Unklarheiten ausgeschlossen sind: Im oben geschilderten Fall vor dem OLG Frankfurt (der vollständige Vertragstext konnte den Urteilen nicht entnommen werden) war eine zweigliedrige Vertragskonstellation aus Letter of Intent und Projektentwicklungsvertrag zumindest beabsichtigt. Angesichts dessen ist es – trotz der Scrum-üblichen Verschlankung der Planungsphase – unumgänglich, die vertraglichen Verhältnisse im Vorfeld zu klären.

Diese Notwendigkeit wird noch deutlicher, wenn man sich vor Augen führt, dass die BGB-Regelungen im B2B-Bereich größtenteils nicht zwingend sind. Die Parteien können den Leistungsgegenstand und die Folgen von Leistungsstörungen auch abweichend von den Vorgaben des BGB regeln. Das insoweit wohl bekannteste Beispiel ist die Möglichkeit zum Ausschluss von Gewährleistungsrechten: Im Streitfall wendet ein Gericht die gesetzlich vorgesehenen Normen nicht an, weil es die Parteien so vereinbart haben. Genauso können sich die Parteien auch im Rahmen eines Softwareprojektvertrags auf etwas einigen, das nicht den im BGB vorgesehenen Vertragstypen entspricht. Anders ausgedrückt: Das Gericht stellt sich nur dann die Frage, ob es Dienst- oder Werkvertragsrecht anwenden soll, wenn der Vertrag zu einem bestimmten Punkt keine ausdrückliche Regelung enthält. Dabei ist selbstverständlich zu beachten, dass kaum jede Eventualität berücksichtigt werden kann. Man kann Unsicherheiten regelmäßig nur minimieren, aber nicht ausschließen.

Nach oben

Nachfolgend finden Sie eine Reihe von Tipps zur Vertragsgestaltung:

1. Vertragsgegenstand und Vorgehensmodell

Da verschiedene agile Vorgehensweisen existieren und die Parteien möglicherweise unterschiedliche begriffliche Vorstellungen haben, sollte das geplante Vorgehen zunächst so konkret wie möglich beschrieben werden.

Wie bereits erwähnt sind die Anforderungen an die zu schaffende Software bei Vertragsschluss typischerweise noch nicht konkret festgelegt. Meist besteht nur eine Vision, die dann gleichzeitig die einzige Beschreibung des Leistungsgegenstandes darstellt. Aus der Vision lassen sich wiederum Rückschlüsse ziehen, welche Ziele die Parteien mit dem Vertrag verfolgen.

Zur grundsätzlichen Einordnung des Vertrages ist es hilfreich, das grundsätzlich gewählte Risikomodell (Werkvertrag/Dienstvertrag) festzuhalten. Dabei ist jedoch nicht zu unterschätzen, dass die Mitwirkung des Auftraggebers auch immer zu mehr eigener Verantwortung für den Erfolg des Projekts führt (s. auch Conrad/Schneider, in: Auer-Reinsdorff/Conrad, Handbuch IT- und Datenschutzrecht, § 11 Rn. 4). Je weiter sich der Vertrag vom klassischen Modell entfernt (= Planung durch den Auftraggeber, Durchführung durch den Auftragnehmer), desto unsicherer wird die Prognose, wie Vertragsverletzungen im Streitfall von einem Gericht beurteilt werden.

Halten Sie im Vertrag fest, welche Anforderungen an die Parteien in welcher Phase zu stellen sind. Dabei sollte die Dauer der jeweiligen Sprints sowie der Turnus der Meetings festgehalten werden.

Nach oben

2. Mitwirkungspflichten des Auftraggebers

Die vertraglich festgehaltene Einbindung des Auftraggebers in den Entwicklungsprozess kann für beide Seiten Vorteile bringen: Durch die Teilnahme an den sprint reviews sind alle Beteiligten über die Vorstellungen und Wünsche des Auftraggebers im Bilde. So können Missverständnisse – und damit unnötige Arbeit – vermieden werden. Es muss aber auch geklärt werden, was passiert, wenn es nicht mehr “rund” läuft.

Nach oben

3. Dokumentationspflichten

In den oben vorgestellten Urteilen spielte auch die Dokumentation eine wesentliche Rolle. Diese kann bei werkvertraglicher Einordnung des Projekts darüber entscheiden, ob die gelieferte Software dem Geschuldeten entspricht.

Nach oben

4. Vergütung / Preise

Besonders relevant und streitträchtig sind die Vergütungsregelungen. Für den Auftragnehmer ist es von Vorteil, eine Vergütung nach Aufwand und Zeit zu vereinbaren (z.B. einen Einheitspreis pro Person/Tag). Damit kann er sicherstellen, dass er nicht unbezahlt arbeitet. Demgegenüber hat der Auftraggebers ein Interesse daran, die Kosten überschaubar, wenigstens aber planbar zu halten. Zwischen diesen beiden Polen liegt der objektiv faire Preis. Diesen wird man in den seltensten Fällen genau treffen. Auch lässt sich kaum pauschal zu einem Modell raten. Eine langfristig gute – und nicht nur einmalige – Zusammenarbeit wird jedoch wahrscheinlicher, je näher man sich einem fairen Preis nähert. Sinnvoll kann es deshalb sein, ein Vorgehen zu wählen, bei dem nach der Erbringung einer brauchbaren Teilleistung jeweils ein Teilbetrag gezahlt wird.

Falls Sie Scrum dahingehend anwenden, dass Sie einen agilen Festpreis vereinbaren, halten Sie auch insoweit die Modalitäten fest.

Nach oben

4. Kündigungsmöglichkeiten

Das Scrum Modell erfordert großes gegenseitiges Vertrauen, das in der Anfangsphase vor allem vom Auftraggeber und später eher vom Auftragnehmer aufzubringen ist. Daher sollten Möglichkeiten zur Loslösung vom Projekt in den Vertrag integriert werden.

Beispielsweise könnte ein Kündigungsrecht zum Ende jedes Sprints vereinbart werden. Das empfiehlt sich besonders, wenn die einzelnen Sprints gesondert vergütet werden und für jeden Sprint eine fest umrissene, eigenständig brauchbare Leistung vereinbart wird. Dies ermöglicht eine gewisse Kostenkontrolle. Gleichzeitig kann im Falle einer unergiebigen Zusammenarbeit das “Schrecken ohne Ende” vermieden werden, dem sich möglicherweise noch ein Rechtsstreit anschließen würde.

Nach oben

5. Abnahme und Gewährleistung

Soweit Sie den Vertrag so ausgestalten, dass die einzelnen Sprints Werkvertragsrecht unterliegen, ist festzuhalten, an welchen Punkten (Teil-)Abnahmen erfolgen sollen. Es ist naheliegend (aber nicht zwingend), dass diese in den sprint reviews erfolgen.

Nach oben

6. Nutzungsrechte

Uneinigkeiten ergeben sich häufig auch bei der Frage der Nutzungsrechte: Während der Auftragnehmer oft davon ausgeht, dass er stets nur einfache Nutzungsrechte überträgt, da er das Programm geschrieben hat, ist der Auftraggeber der Auffassung, ausschließliche Nutzungsrechte erworben zu haben, da es sich um eine von ihm bezahlte Auftragsarbeit handelt. Problematisch wird dies spätestens dann, wenn der Auftraggeber Unterlizenzen erteilen oder der Auftragnehmer das Programm anderweitig vermarkten möchte.

Fehlt es an einer Absprache, richtet sich die Rechteeinräumung nach § 31 Abs. 5 UrhG (sog. Zweckübertragungslehre). Danach werden Nutzungsrechte nur insoweit eingeräumt, als es zur Erfüllung des Vertrages erforderlich ist. Praktisch wird der Streit damit jedoch nicht gelöst, sondern auf die Frage verlagert, welche Rechteübertragung zur Erfüllung des Vertrages erforderlich ist. Dabei ist zwar regelmäßig davon auszugehen, dass bei vereinbarter individueller Nutzung einfache, bei vereinbarter Weitervermarktung ausschließliche Rechte eingeräumt werden; im Einzelfall haben Gerichte aber auch schon hiervor abweichende Entscheidungen getroffen (Grützmacher, in: Wandte/Bullinger, PK-UrhR, § 69a UrhG, Rn. 64).

Nach oben

7. Vertragsgestaltung bei anderen agilen Methoden

Neben Scrum existieren noch weitere agile Entwicklungsmethoden wie Kanban, Crystal, XP oder RAD, deren Ansätze sich teilweise ähneln. Bei diesen Methoden ist es ebenfalls kaum möglich, pauschale Vorlagen zu entwickeln. Die obigen Punkte sollten dabei aber ebenfalls berücksichtigt werden. Auch wenn sich agile Methoden gerade dadurch auszeichnen, sich auf das Wesentliche, die Softwareentwicklung zu konzentrieren und möglichst unbürokratisch zu sein: Sobald im Streitfalle Juristen mit der Sache befasst sind, werden sie versuchen, das was sie vor sich haben, in ein ihnen bekanntes Schema einzuordnen, was für beide Seiten das Potenzial unangenehmer Überraschungen birgt. Das einzige Gegenmittel sind möglichst klare Absprachen zu allen wesentlichen Punkten.

Nach oben

An diesem Beitrag hat unsere wissenschaftliche Mitarbeiterin Frau Lisa Marie Uhe mitgewirkt.