Agile Projekte, agile Verträge – Klappe, die Zweite

Schon 2016 widmete sich ein Blogbeitrag der vertragstypologischen Einordnung eines Softwareentwicklungsvertrages, in welchem ein Vorgehen nach SCRUM vereinbart wird. Zum damaligen Zeitpunkt lag Rechtsprechung hierzu noch nicht vor.
Dies hat sich nun geändert. In zwei Instanzen beschäftigten sich hessische Gerichte mit einem agilen Sachverhalt (Landgericht Wiesbaden, Urteil vom 30.11.2016 – 11 O 10/15 und OLG Frankfurt a. M., Urteil vom 17.08.2017 – 5 U 152/16). Grund genug, dem Thema agile Softwareentwicklung einen weiteren Blogbeitrag zu widmen und hierbei insbesondere die Themen Vertragstyp und Dokumentation zu betrachten.

I. Sachverhalt

Ausgangspunkt der Auseinandersetzung war der Abschluss eines „Letter of Intent“ (LOI) über die Erstellung einer Internet-Plattform. Der eigentliche Projektvertrag wurde zwischen den Parteien verhandelt, aber letztlich nicht unterzeichnet. Einig waren die Parteien aber, dass die Softwareentwicklung agil nach SCRUM und die Vergütung nach „time & material“ erfolgen sollte. Hierzu wurde eine Ratenzahlungsvereinbarung getroffen. Nachdem eine Monatsrate durch den Auftraggeber ausblieb, kündigte der Auftragnehmer die Vereinbarung. Die Parteien verhandelten anschließend eine Projektbeendigung gegen Zahlung eines weiteren Betrages. Eine Einigung kam offenbar nicht zustande.

Der Auftragnehmer verlangte Vergütung für bereits erbrachte Leistungen, während der Auftraggeber die Auffassung vertrat, dass die Leistungen des Auftragnehmers unbrauchbar waren.

II. Erstinstanzliches Urteil des LG Wiesbaden

Das Landgericht sah die Vergütungsklage des Auftragnehmers als unbegründet ab. Es stellte darauf ab, dass in dem nicht unterzeichneten Projektvertrag der Wille der Parteien zum Ausdruck komme, das Projekt nach werkvertraglichen Grundsätzen durchzuführen. Entscheidend sei die erfolgreiche Realisierung der Plattform und nicht die Tätigkeit des Auftragnehmers gewesen. Innerhalb der verschiedenen Sprints seien die zu erledigenden Aufgaben und deren Umfang konkret festgelegt gewesen. Eine Vergütungsvereinbarung „time & material“ stehe einer werkvertraglichen Einordnung nicht entgegen.

Das Gericht lehnte den Vergütungsanspruch ab, da der vom Landgericht hinzugezogene Sachverständige zu dem Ergebnis kam, dass die vom Auftraggeber erbrachten Teilleistungen mangels einer übergreifenden System-/Architektur-Dokumentation unbrauchbar und somit letztlich wertlos für den Auftraggeber gewesen seien. Das Gericht ließ den Einwand des Auftregnehmers nicht gelten, dass mangels anderweitiger Vereinbarung erst mit Abnahme eine Enddokumentation fällig sei. Der verhandelte Vertragsentwurf habe eine Dokumentation der einzelnen Schritte und Arbeitsergebnisse durch den Auftragnehmer im laufenden Prozess vorgesehen.

Man kann darüber diskutieren, ob diese Entscheidung die bisherige Auffassung des Bundesgerichtshofs hinreichend berücksichtigt, nämlich dass eine Dokumentation erst mit Abschluss der Entwicklungsarbeiten an der Software geschuldet ist (BGH, Urteil vom 20.02.2001 – X ZR 9/99) und ob diese Auffassung auch für agile Projekte zu berücksichtigen wäre. Da das Landgerichts-Urteil aber nicht rechtskräftig geworden ist, soll zunächst noch das OLG-Urteil betrachtet werden.

III. Berufungsurteil des OLG Frankfurt

Das OLG hob die erstinstanzliche Entscheidung auf und entschied zugunsten des Auftragnehmers. Es ließ allerdings – anders als das Landgericht – ausdrücklich offen, ob auf das Vertragsverhältnis der Parteien Dienst- oder Werkvertragsrecht anwendbar sei. Wäre Dienstvertragsrecht anwendbar, wäre die geforderte Vergütung schon deshalb fällig, da die abgerechneten Leistungen durch den Auftragnehmer unstreitig erbracht wurden. Aber auch bei einer Zugrundelegung von Werkvertragsrecht war aus Sicht der Berufungsrichter die Klage begründet. Dabei nahm das Gericht nicht dazu Stellung, ob sich dies schon aus dem agilen Vorgehensmodell ergebe, nach dem der exakte Leistungsumfang pro Monat geplant werde. Man könne in der jeweiligen Beauftragung für den Folgemonat eine konkludente Abnahme des bislang Geleisteten sehen. Jedenfalls aber seien die Monatsrechnungen nach der von den Parteien getroffenen Ratenzahlungsvereinbarung nicht als bloße Abschlagszahlungen sondern dahingehend zu verstehen, dass der Auftraggeber die bis dahin erbrachten Leistungen des Auftragnehmers als grundsätzlich vertragsgerecht und den geltend gemachten Zahlungsanspruch deswegen als fällig anerkennen wollte.

Auf die sachverständigen Ausführungen zur Dokumentation geht der Senat näher ein. So sei im Gutachten festgestellt worden, dass der Quellcode durch den Auftraggeber durchaus – wenn auch „äußerst knapp“ und „fachlich nicht überall als ausreichend zum Verständnis“ – kommentiert war. Einen relevanten Mangel habe der Sachverständige aber nicht konstatiert. Hinsichtlich des Fehlens der System-/Architektur-Dokumentation führte der Senat aus, dass die Auftragnehmerin unwidersprochen vorgetragen habe, dass diese Dokumentation erst erfolgen könne und sinnvoll sei, wenn die Systemarchitektur und die letztlich eingesetzten Komponenten feststünden. Der Auftraggeber wiederum habe nicht vorgetragen, dass dies trotz agiler Softwareentwicklung bereits zum Zeitpunkt der Projektbeendigung der Fall war.

IV. Fazit

Nachdem bislang nur in der juristischen Literatur diskutiert wurde, welchem Vertragstyp agile Projekte unterfallen, liegt mit der Entscheidung des LG Wiesbaden nun ein erstes – wenn auch nicht rechtskräftiges – Urteil vor, welches sich diesbezüglich festlegt.

Hinsichtlich der Fälligkeit einer Dokumentation lässt sich der OLG-Entscheidung wenig „allgemeingültiges“ entnehmen. Eine inhaltliche Auseinandersetzung mit der Frage, ob (und wann) eine (jedenfalls dem aktuellen agilen Projektstand entsprechende) System-/Architektur-Dokumentation – geschuldet ist, bleibt durch Formulierungen wie „unwidersprochen vorgetragen“ und „nicht vorgetragen“ offen.

Kommen wir zurück auf die bisherige, oben erwähnte BGH-Rechtsprechung: Nach hiesiger Auffassung ist diese Entscheidung nicht eins zu eins auf agile Projekte übertragbar. Bei Wasserfallprojekten verfügt der Auftraggeber aufgrund des Pflichtenhefts bereits zu einem frühen Zeitpunkt über eine Beschreibung des zu erstellenden Systems, welches nicht nur die Funktionalitäten beschreibt, sondern auch Aussagen zur Architektur enthält. Im Fall eines Projektabbruchs könnte zumindest das Pflichtenheft einem neuen Dienstleister zur Verfügung gestellt werden.

Im agilen Projekt entfällt die Spezifikationsphase und die Anforderungen werden im laufenden Projekt entwickelt. Gleichwohl kann sich ein Projektteam nicht ausschließlich der Programmierung widmen, denn SCRUM schafft Dokumentation nicht ab. Um Abhängigkeiten und Zusammenhänge innerhalb des Gesamtsystems berücksichtigen zu können, muss diese laufend erfolgen. Zudem wird gerade bei der Entwicklung komplexerer Systemen über längere Dauer Wissen aus früheren Projektphasen benötigt. Bei einem Projektabbruch kann sich der Auftragnehmer daher nicht darauf berufen, dass Architekturdokumente noch nicht vorliegen (können), insbesondere wenn in den vorab erteilten Beauftragungen für die einzelnen Monate eine Billigung des Auftraggebers der bisher geleisteten Arbeiten zu sehen sein soll.

V. Umsetzung in der Praxis

Da das Thema Dokumentation für agile Projekte rechtlich noch nicht geklärt ist, ist beiden Projektparteien zu empfehlen, vertraglich zu vereinbaren, welche Dokumentation der Auftragnehmer zu welchem Zeitpunkt bereitstellen können muss. Auch auf die Qualität der Dokumentation sollte eingegangen werden  und so sichergestellt werden, dass nach angemessener Einarbeitungszeit mit der Programmiersprache vertraute Entwickler das Projekt übernehmen könnten.