Neue Dimensionen des Softwareentwicklungsvertrages?

Das OLG Frankfurt v. 17.7.2017 - 5 U 152/16 (demnächst in CR mit Besprechungsaufsatz Welkenbach) hat das Urteil des LG Wiesbaden zu Scrum abgeändert und den Vergütungsanspruch zugesprochen. Die Fälligkeit ergibt sich aus dem LoI und demVerfahren mit Einzelbeauftragung, monatlicher Abrechnung und Planung i.V.m. Ratenzahlungsvereinbarung. Eine Einordnung als Werkvertrag wurde dabei als nicht entscheidend angesehen (anders LG Wiesbaden v. 30.11.2016 - 11 O 10/15, CR 2017, 298 = ITRB 2017, 36).

Sensationell ist nicht das Ergebnis, sondern die Begründung und der Argumentationsweg des OLG Frankfurt zur agilen Methodik. Dies bleibt nicht ohne Folgen für die künftige Gestaltung agiler Projekte, auch wenn wichtige Fragen offen geblieben sind.

Ansatz des LG Wiesbaden

Tatsächlich hatte das LG Wiesbaden zwar die agile Methodik nicht wirklich adäquat gewürdigt, aber immerhin gab es damit eine Entscheidung zum Vertragstyp bei Scrum. Es darf angenommen werden, dass viele Projekte von den Ausführenden agil betrieben werden, auch wenn der Vertrag das gar nicht ausweist. Erst recht stellt sich aber die Frage des Vertragsytyps, wenn das Vorgehen gemäß agilem Mainifest oder speziell nach Scrum vertraglich vereinbart wurde.

Das LG Wiesbaden hatte zur Verantwortungszuordnung befunden:

„1. Auch bei einer interaktiven Internetplattform, die mittels agiler Softwareerstellung im sog. SCRUM-Verfahren beauftragt ist, verbleibt es bei der Konzeptionshoheit des Auftraggebers einerseits und der Ausführungsverantwortlichkeit des Auftragnehmers andererseits.“ (LG Wiesbaden v. 30.11.2016 - 11 O 10/15, CR 2017, 298)

Daraus ergibt sich also werkvertragliche Einordnung. Dass dieser Einordnung einer Abrechnung nach Zeitaufwand nicht entgegensteht, war schon klar (wozu LG Wiesbaden sich BGH, Urteil vom 25. März 1993 – X ZR 17/92, CR 1993, 759 anschloss). Ernst hat die Entscheidung des LG Wiesbaden umfassend, auch kritisch, gewürdigt (Ernst, CR 2017, 285) und die bisherige Diskussion weitergeführt (s. zur Lit. dort Fn. 1).

Ansatz des OLG Frankfurt

Das OLG Frankfurt entschied nicht, ob generell entweder Werk- oder Dienstvertrag, ob teilweise mal Werk- oder Dienstvertrag greift. Es hält es für möglich, dass beide Vertragstypen nebeneinander oder abwechselnd für den einzelnen Vertrag gelten.

Zu diesem Ergebnis gelangt das OLG Frankfurt auf folgendem Argumentationsweg:

• Scrum-Grundsätze? Die Scrum-Grundsätze werden vom OLG Frankfurt weder besonders behandelt noch gewürdigt. Insbesondere wird nicht auf die spezifische Ausprägung von bestimmten Rollen, die für das Projekt zu vergeben sind, eingegangen, ebensowenig wie die Besetzung durch die Parteien.
• Dokumentation der Systemarchitektur: Einen Aspekt jedoch greift das OLG Frankfurt zentral auf, der ein wichtiger Teil der Projekt-Methodik ist: Die Dokumentation der Systemarchitektur und ihrer Komponenten, die lt. Gericht von der Kommentierung der Quellcode-Dateien zu unterscheiden sind, mögen zwar geschuldet sein. Dass dies aber bereits zum Zeitpunkt des Abbruchs der Programmierungsarbeiten geschuldet war, ist für das Gericht nicht ersichtlich. Diese Leistung könnte erst erfolgen bzw. sei erst sinnvoll, wenn die Systemarchitektur und die letztendlich verwendeten Komponenten feststehen.
• Projektstop = Kündigung? Bei dem vorzeitigen Abbruch per Projektstop spielte die Frage, ob nicht eine Kündigung nach § 649 BGB vorliegt, übrigens weder beim LG Wiesbaden noch beim OLG Frankfurt eine Rolle.
• Agile Methodik: In diesem Zusammenhang aber geht das OLG Frankfurt auf die Methode ein. Nachdem es zuvor festgestellt hat, dass die als noch fehlend von der Klägerin beanstandeten Leistungen erst erfolgen können bzw. sinnvoll sind, wenn die Systemarchitektur und die letztlich verwendeten Komponenten feststehen, geht das OLG Frankfurt auf die agile Methodik ein. Dies allerdings leider nur negativ:               „Dass dies trotz des ‚agilen‘, fortlaufend korrigierten Systems der Softwareerstellung bereits zu diesem Zeitpunkt der Fall war, hat die Beklagte nicht vorgetragen.“

  Das bedeutet, dass das OLG Frankfurt den spezifischen agilen Prozess als u. a. auch fortlaufende Korrektur des Systems (des Programms) als vertragsrelevant und damit als entscheidend für die Verteilung und Ausprägung der beiderseitigen Pflichten verstand.

• Typische Vorgehensweise: Die konkrete Ausprägung hatten die Parteien im konkreten Fall zwar nur rudimentär geregelt, aber zumindest praktiziert, wenn nicht konkludent vereinbart: Die Parteien hatten eine für agile Methodik typische Vorgehensweise gehandhabt, wonach in LoI vereinbart war, dass der jeweilige exakte Leistungsumfang pro Monat einvernehmlich in den dafür vorgesehenen Gremien und Mechanismen der Scrum-Methodik geplant werden sollte, und dass jeweils nachschüssig die für den jeweiligen Monat geschuldete Grundvergütung „nach dem tatsächlich geleisteten Aufwand abgerechnet werden sollte“. Insofern zieht es das OLG Frankfurt zumindest in Betracht, dass in der jeweiligen Beauftragung für den Folgemonat eine Billigung des bisher Geleisteten i. S. einer zumindest konkludenten Abnahme zu sehen ist. Dabei spielte auch eine Rolle, dass es sich insoweit nicht um Abschlagszahlungen handelt. Zudem war im konkreten Fall Ratenzahlung vereinbart worden. Für eine Verallgemeinerung erscheint zentral, dass die in diesem Fall periodisch erfolgende (nicht auf ein bestimmtes Ergebnis) abstellende Abrechnung des bereits geleisteten und Planung des nun folgenden Abschnitts zugleich auch eine Methodik ist, fortlaufend zu korrigieren. Insofern ist dann auch verständlich, weshalb der mehr experimentelle Charakter nichts an der möglichen werkvertraglichen Einordnung ändert bzw. das OLG Frankfurt davon spricht, dass der streitgegenständliche Vertrag ganz oder teilweise dem Dienst- oder dem Werkvertragsrecht zu unterstellen ist.

Kombination bisheriger Literaturansätze:

Damit werden praxisrelevant zwei Vorschläge auf einfache Weise miteinander kombiniert, wie agile Projekte einzuordnen sind:

• Koch, ITRB 2010, 114 ff. hatte als plausibel vorgeschlagen, dass das Entwickeln einer ersten Fassung einer lauffähigen und demonstrierbaren Grundfunktionalität dem Werkvertragsrecht unterliegen könnte und die - zumal mündlich gesteuerte, quasi auf Zuruf erfolgende – Weiterentwicklung und Ausgestaltung der ersten Fassung hingegen Dienstvertragsrecht (Koch, ITRB 2010, 114, 119).
• Frank, CR 2011, 138 ff. hatte demgegenüber vorgeschlagen, die Gegenstände der Zusammenarbeit abzuschichten und dabei die verschiedenen Iterationen getrennt zu sehen. Frank hätte insofern also, anders die periodische Betrachtung des OLG Frankfurt, jeden Sprint als marktüblich angesehen. Er empfiehlt, die Planung und Realisierung zu trennen – was sich ja auch beim traditionellen Projekt empfehlen würde. Danach würde dann die Planung eher nach Dienstvertrag, die Realisierung nach Werkvertrag beurteilt. Dies würde natürlich die entsprechende Trennung trotz der instrumentalen Entwicklungsmethodik voraussetzen (Frank, CR 2011, 138, 141 f.).

Folge für Vertragsgestaltung bei agiler Methodik ohne klare Sprints

Zumindest für agile Projekte, bei denen die genaue Abtrennung der einzelnen Sprints und der Planungsarbeiten dafür nicht praktiziert wird bzw. möglich erscheint, dürfte das Urteil des OLG Frankfurt eine ganz wesentliche Maßgabe auch für die Vertragsgestaltung enthalten. Es könnte sich empfehlen, genau diese iterative Schrittfolge mit dem Kontrollpunkt zwischen den beiden Zeitabschnitten/Projektabschnitten (etwa ähnlich früheren Meilensteinen) als die Kombination von Billigung des bisher Geleisteten – unabhängig davon, ob es sich um Teilabnahmen handelt – und zugleich damit Abrechnung des Aufwands und dessen Billigung zu sehen und sodann die Festlegung der Planung für den nächsten (Zeit-)Abschnitt.

Es soll aber nicht außer Acht bleiben, dass damit ein gewisser zeitlicher Stop verbunden ist, das Projekt evtl. also für ein paar Tage ruhen müsste, weil sicher die Abrechnung erst qualifiziert erfolgen und geprüft werden muss.

Offen gebliebene Fragen zur Dokumentation

Vielleicht ist aber an dem ganzen Urteil noch viel wichtiger, was nicht mit-entschieden worden ist.

• Das „Ob“: Dazu gehört etwa, dass die Frage, ob überhaupt bestimmte Dokumentationen geschuldet sind und nicht diese der Auftraggeber zu erstellen hätte (wenn nicht ausdrücklich der Auftragnehmer dies machen soll) nicht behandelt wird.
• Rollenverteilung der Parteien: Auch die Rollenverteilung und deren Auswirkung werden nicht behandelt.
• Fälligkeit: Konkret ging es um die „von der Kommentierung der Quellcode-Dateien zu unterscheidende Dokumentation der Systemarchitektur und ihrer Komponenten“ und deren Fälligkeit. Nachdem diese erst gegen Ende des Projekts feststehen, ist auch deren Dokumentation nicht vorher zu leisten (s.a. auch zur traditionellen Dokumentation BGH v. 20.2.2001 – X ZR 9/99 , CR 2001, 367 m. Anm. Hoene).

Change Request?

Typisch für Scrum ist, dass beim Realisieren Abweichungen gegenüber dem für den jeweiligen Sprint bzw. die jeweilige Periode aufgestellten Plan erfolgen und somit die Frage zu stellen ist, inwieweit es sich hier um Änderungen im Sinne von Change Request handelt. Das OLG Frankfurt scheint geneigt zu sein, diesen inkrementellen Änderungsprozess als im Hinblick auf die Aufwandsermittlung unproblematisch zu sehen, d. h.: es ist nicht notwendig, jeweils die Änderungen zu vereinbaren.

Qualitätsmaßstab?

Andererseits spielt in dem Urteil auch keine Rolle, ob ansonsten irgendwelche Maßstäbe für die Beurteilung des Ergebnisses gegeben sind, wie etwa der mittlere Ausführungsstandard. Dies bedeutet nicht, dass nicht etwa auf diese Rechtsprechung des BGH zurückgegriffen werden könnte. Jedoch liegt nach der Entscheidung des OLG Frankfurt näher, dass trotz des (teils) werkvertraglichen Charakters es die Parteien durch die Handhabung des Projekts selbst in der Hand haben, welchen Maßstab sie insofern dann doch (periodisch) festlegen. Das Backlog als „Pflichtenheft“ i.S. der BGH Rspr. anzusehen, erscheint verfehlt (s.a. zum urheberrechtlichen Aspekt: Schneider in: Schneider, Handbuch EDV-Recht, 5. Aufl. 2017, G. Rz. 81, zur Abfolge der Schritte im Gegensatz zu Wasserfall ebenda, N. Rz. 53 ff.)

Fazit für Projekt- und Vertragsgestaltung

Bei agiler Projektgestaltung bzw. Projekt-Beurteilung würde es also nicht mehr notwendig sein, die Vertragstypik aus der typischen Anlage von Sprints heraus zu entwickeln (also den Ablauf, der im Grunde genommen sehr genau vorgeschrieben ist, von der Definition des Ziels über die Planung einzelner Schritte zur Dokumentation in Backlog und dann die Umsetzung bis hin zum Review und auch zum Abgleich mit dem Product Backlog (dazu auch Frank, CR 2011, 138 ff.; Koch, ITRB 2010, 114, 116; zur agilen Projektmethodik s. a. Schneider in: Schneider/Graf v. Westphalen, Software-Erstellungsverträge, 2. Aufl., Kap. C Rz. 113 ff., 124 ff., 131).

Urheberrechtlich könnte es sehr relevant werden, wie der Vertrag und die Praxis die Übergabe gestalten, soweit davon Rechtseinräumung und deren Zeitpunkt abhängen. Zudem könnte bei Dienstvertrag in Verbindung mit GbR eine nur gemeinschaftliche Ausübung der Rechte möglich sein, wenn geeignete Klauseln anderen Inhalts fehlen. Insofern wird es sich empfehlen, einen an sich sehr „schlanken“ Vertrag, der die Möglichkeiten gemäß OLG Frankfurt ausschöpft, um Regelungen zu Rechtseinräumung auch im Falle eines Exits nach § 649 BGB oder einfach einer Beendigung durch das Ausbleiben weiterer Beauftragung vorzusehen.