Das Landgericht Bonn, 10 O 296/19, hatte sich mit der Frage zu befassen, wie zu verfahren ist, wenn eine agile Softwareentwicklung scheitert und das Projekt trotz bereits erbrachter Leistungen abgebrochen werden soll. In diesem Fall ging es um die Frage, ob ein Rücktritt vom Vertrag möglich ist. Das Landgericht kam in diesem Fall zu dem Schluss, dass der Kläger durch den erklärten Rücktritt nicht von dem gesamten Vertrag zurücktreten und Rückabwicklung auch hinsichtlich der bereits erbrachten und vergüteten Teilleistungen (Inkrements) verlangen konnte.
Ablauf des Projekts
Im vorliegenden Fall hat die Beklagte mit den gelieferten Inkrementen (Sprints) Teilleistungen erbracht, die der Kläger abgenommen und durch Zahlung der streitgegenständlichen Rechnungen vergütet hat. Dies entsprach der vereinbarten Vorgehensweise im sog. agilen Vorgehen (Scrum).
Bereits in der Präambel des Vertrages hatten die Parteien festgelegt, dass die Entwicklung in Etappen (Sprints) erfolgen und jeder Sprint mit der Übergabe eines in sich vollständigen Softwareprodukts (getestetes Inkrement einer lauffähigen Software, vgl. Ziff. 3 der Präambel) abgeschlossen sein sollte. Kern des Vorgehens war eine von Sprint zu Sprint schrittweise Verbesserung und Weiterentwicklung des Produkts auf der Grundlage eines entsprechend kontinuierlich zu verfeinernden und zu verbessernden langfristigen Plans (Product Backlog). Dies schließt ein, dass die ausgelieferten Sprints zwar für sich genommen funktionsfähige Software darstellen, die alle Qualitätskriterien gemäß Anlage C (Präambel) erfüllt, dass diese aber in den nachfolgenden Sprints weiter verbessert und an die von der Klägerin definierten und im Product Backlog nachzuverfolgenden Anforderungen weiter angepasst wird.
Mit der Abnahme der den streitgegenständlichen Rechnungen zugrunde liegenden Sprints hat der Kläger gemäß § 5 Abnahme des Vertrages die grundsätzliche Vertragsgemäßheit der jeweiligen Softwarelieferungen (Produktinkremente) hinsichtlich Funktionalität, Quellcode und Dokumentation erklärt. Dort heißt es: „(…) Diese Teilabnahme umfasst den Quellcode, die Funktionalität und die Dokumentation des gesamten Softwareinkrements“.
Voraussetzungen eines Rücktritts vom Vertrag
Nach § 323 Abs. 5 Satz 1 BGB kann der Gläubiger bei erbrachten Teilleistungen nur dann vom ganzen Vertrag zurücktreten, wenn er an der Teilleistung kein Interesse hat. Bezugspunkt für die Beurteilung des Gläubigerinteresses ist der bereits erbrachte, nicht der noch ausstehende Teil der Leistung. Es geht also um das Interesse an dem verminderten beiderseitigen Leistungsaustausch.
Das fehlende Interesse an der Teilleistung bestimmt sich dabei objektiv, wenngleich unter Berücksichtigung der individuellen Verhältnisse des Gläubigers. Ob dieses Gläubigerinteresse vom Schuldner erkannt wurde oder für ihn auch nur erkennbar war, spielt keine Rolle. Entscheidend für das fehlende Interesse ist also, ob der Gläubiger nach seinen Verhältnissen bei objektiver Würdigung kein Interesse mehr daran hat, die bereits empfangene Teilleistung gegen eine entsprechend geminderte Gegenleistung zu erhalten, insbesondere weil sein konkreter Zweck auch mit der Teilleistung nicht erreicht werden kann und er sich die fehlenden Teile nicht oder nur mit Schwierigkeiten beschaffen kann. Maßstab ist das ursprünglich vom Gläubiger verfolgte Vertragsinteresse. Entscheidend ist, dass das Interesse des Gläubigers durch die Teilung unverhältnismäßig beeinträchtigt wird.
Das Interesse an der Gesamtleistung des Schuldners muss über den Entzug des vorenthaltenen Teils hinaus beeinträchtigt sein, so dass das Interesse des Gläubigers auch bei einem Teilrücktritt verletzt bliebe. Dann und nur dann ist ein vollständiger Rücktritt zulässig. Der Wegfall des Interesses muss seine Ursache darin haben, dass der Schuldner nur teilweise geleistet hat; andere Gründe sind unbeachtlich. Der Gläubiger trägt die Beweislast.
Mangelhafte Leistung
Die Voraussetzungen für einen (Gesamt-)Rücktritt auch hinsichtlich der streitgegenständlichen Teilleistungen lagen aus Sicht des Gerichts jedoch nicht vor: Denn der Kläger hatte einen Wegfall des Interesses nicht dargelegt und bewiesen.
Den Wegfall des Interesses an den bereits erbrachten und unstreitig abgenommenen Teilleistungen (Inkremente, Sprints) hat der Kläger im Wesentlichen damit begründet, dass das bisher gelieferte Produkt nicht ausreichend skalierbar und barrierefrei gewesen sei und der Datenschutz nicht im erforderlichen Umfang gewährleistet gewesen sei. Darüber hinaus und insbesondere habe die Beklagte die vertraglich geschuldete ordnungsgemäße Dokumentation unterlassen, weshalb dem Kläger die vertragsgemäße Nutzung der bereits gelieferten Softwareteile nicht oder nur mit unverhältnismäßig hohem finanziellem Aufwand möglich sei.
Dabei ging das Gericht sogar davon aus, dass die Beklagte die von ihr bereits gelieferten Software-Inkremente nicht mit einer ausreichenden und vertraglich geschuldeten Dokumentation versehen habe. So wurde durch Sachverständigengutachten nachgewiesen, dass die Beklagte die vertraglich geschuldete Inline-Dokumentation im Quellcode, die Designdokumentation sowie die Anforderungsdokumentation nicht oder nur mangelhaft erstellt hatte:
Die Erstellung einer Inline-Dokumentation – einer Beschreibung bzw. Kommentierung des Quellcodes – war zwischen den Parteien ausweislich Anlage C i.V.m. § 1 e) des Vertrages vereinbart. Dort heißt es (Anlage C, Anl. LP2, Bl. 245 d.A.): „Am Ende eines jeden Sprints wird dem Kunden ein lauffähiges, getestetes und dokumentiertes Produktinkrement nach folgenden Kriterien übergeben: (….) 5. Der Quellcode wurde dokumentiert, wenn neuer Code erstellt wurde und dieser nicht selbsterklärend ist.“ Dokumentation in diesem Sinne ist nach der Definition in § 1 e) des Vertrages u.a. die Inline-Dokumentation.
Sinn und Zweck dieser Dokumentation ist es, die Weiterverarbeitung und Wartbarkeit der Software durch (nicht an der Entwicklung der Software beteiligte) Dritte zu ermöglichen. Nach den Feststellungen des Sachverständigen enthalten die von der Beklagten erstellten Inkremente „so gut wie keine Inline-Kommentierung im Sinne des Wortlauts und der Intention der vertraglichen Vereinbarung“. Die erstellte Inline-Dokumentation sei mangelhaft; die meisten Kommentare enthielten „keine hilfreichen Informationen“, sondern wiederholten lediglich Informationen, die auch unmittelbar aus dem Code ersichtlich seien. Insgesamt stellte der Gutachter einen Kommentierungsgrad von 2,67 Prozent im funktionalen Code (ohne Testcode) fest. Bei einer guten Inline-Kommentierung liegt der Wert jedoch bei 15 Prozent, bei einer Kommentierung mittlerer Art und Güte immerhin noch bei 10-15 Prozent.
Ebenso fehlte nach dem Ergebnis des Gutachtens die sog. Design-Dokumentation, die alle wesentlichen Design-Entscheidungen enthält und auf deren Grundlage Wartungs- und Weiterentwicklungsarbeiten an der Software mit vertretbarem Aufwand durchgeführt werden können.
Dabei handelt es sich um Informationen, die sich nicht bereits aus dem Quellcode ableiten lassen und die erforderlich sind, um sich im Quellcode mit seinen hunderten von Dateien und tausenden von Programmobjekten zurechtzufinden und die Zusammenhänge zwischen diesen Artefakten effektiv nachvollziehen zu können, und zwar in einer für Dritte verständlichen und leicht zugänglichen Form.Die Erstellung einer solchen Designdokumentation, die als Kombination aus Architektur- und Entwicklungsdokumentation anzusehen ist, wurde von den Parteien in Ziffer 5 des Appendix C vereinbart.Danach war der neu erstellte Quellcode zu dokumentieren, „soweit er nicht selbsterklärend ist“. Zur Dokumentation gehörte nach der Definition in § 1 e) des Vertrages auch das „Designdokument“.In jedem Sprint wäre demnach eine Gesamtdarstellung als jeweils aktualisierte Softwarearchitekturdokumentation zu liefern gewesen.Die Beklagte hat jedoch kein Designdokument erstellt; aus dem gelieferten Quellcode lässt sich die Designdokumentation nicht ableiten.
Ebenso fehlte nach den Feststellungen des Sachverständigen die von der Beklagten geschuldete Anforderungsdokumentation.Diese hätte insbesondere durch eine sorgfältige und im laufenden Projekt immer wieder zu aktualisierende Dokumentation der sog. User Stories und deren Fortschreibung im sog. Product Backlog erfolgen müssen. Beides oblag nach den vertraglichen Vereinbarungen letztlich der Beklagten: Sie hatte die Vorgaben aus dem Lastenheft für die Projektdurchführung in sinnvolle Epics umzusetzen und die in Epics beschriebenen Anforderungen in sog. User Stories zu untergliedern. Hierbei handelt es sich um einfach gehaltene Anforderungsbeschreibungen, die dann – im Wege einer Entwicklungsstufe (Sprint) – umzusetzen waren.
Nach § 6 a) des Vertrages in Verbindung mit den Regelungen der Präambel oblag zwar die Spezifikation und Abstimmung der Anforderungen durch User Stories/Sprints dem Kläger gemeinsam mit der Beklagten. Nach § 5 des Vertrages oblag es jedoch der Beklagten, das Projekt, die Dokumentation und damit auch den Quellcode während der Projektdurchführung jederzeit so zu dokumentieren, dass eine Weiterentwicklung durch Dritte möglich ist. Dies schließe notwendigerweise auch die Dokumentation der Anforderungen des Klägers ein. Damit oblag der Beklagten nicht nur die Dokumentation des jeweiligen Arbeitsergebnisses, sondern auch die Dokumentation des Projekts insgesamt, die mit jedem Sprint aktualisiert wurde. Dafür spricht auch, dass die Beklagte dem Kläger nach § 4 des Vertrages das Urheberrecht an den User Stories als Teil der Projektdokumentation einräumte.
Praktisch bedeutete dies nach den Ausführungen des Sachverständigen, denen sich das Gericht anschloss, dass „die Klägerin mit der Lieferung des Quellcodes nach jedem Sprint einen aktualisierten Satz von User Stories erwarten konnte, in dem die Einträge in den bearbeiteten User Stories entsprechend dem tatsächlich implementierten Softwarestand ergänzt bzw. vervollständigt und die im Rahmen von Diskussionen und Detailklärungen gesammelten Informationen beigefügt waren (…)“.
Darüber hinaus oblag es der Beklagten, die User Stories zu einem Product Backlog zusammenzustellen, das nach den vertraglichen Vereinbarungen der Parteien eine vollständige Beschreibung des Vertragsgegenstandes enthalten sollte (§ 1 a) des Vertrages). Nach den Ausführungen des Sachverständigen liegen zwar – teilweise inkonsistent und unsystematisch geführte – User Stories vor. Ein aktuelles Product Backlog im Sinne einer aktuellen, vollständigen und konsistenten Beschreibung des Vertragsgegenstandes, aus dem der aktuelle Planungs- und Umsetzungsstand hervorgeht, fehlt jedoch.
Kein Rücktritt trotz Mängel
Trotz dieser vom Sachverständigen festgestellten Dokumentationsmängel war für das Gericht jedoch nicht von einem Wegfall des Interesses des Klägers an den erbrachten und abgenommenen Teilleistungen auszugehen. Denn ein – mangels Restleistung – entfallenes Interesse an den bereits erbrachten und abgenommenen Teilleistungen kann der Kläger nicht mit deren Mangelhaftigkeit begründen.
Vielmehr hätte er hinsichtlich dieser Mängel seine Rechte aus § 634 BGB geltend machen und der Beklagten (unter Fristsetzung) Gelegenheit zur Nacherfüllung geben müssen. Nach erfolgloser Nachfristsetzung – aber auch nur dann – hätte der Kläger den Rücktritt hinsichtlich der jeweiligen Teilleistungen erklären können. Dies ergibt sich bereits aus dem Vorrang des Mängelgewährleistungsrechts vor dem allgemeinen Leistungsstörungsrecht unter Berücksichtigung der vertraglichen Vereinbarungen der Parteien.
So lag dem Gesamtprojekt die Idee der schrittweisen Lieferung von Softwareinkrementen in einem agilen Vorgehen (Scrum) zugrunde. Danach war die Beklagte verpflichtet, der Klägerin „am Ende eines jeden Sprints (…) ein lauffähiges, getestetes und dokumentiertes Produktinkrement“ zur Verfügung zu stellen, das den Qualitätsanforderungen der Anlage C entsprach, also u.a. über einen „dokumentierten Quellcode“ verfügen musste und für das Frontend- und Unit-Tests durchgeführt worden waren. Diese Qualitätsanforderungen an die jeweiligen Inkremente einerseits und deren Vergütung andererseits sollen es nach dem Vertragsgedanken beiden Parteien ermöglichen, das Projekt nach § 7 des Vertrages jederzeit zu beenden oder an einen dritten Auftragnehmer zu übertragen.
Dieser Gedanke wird in § 7 explizit zum Ausdruck gebracht, wenn es dort heißt: „Da einerseits der Auftragnehmer nach jedem Sprint eine für den Auftraggeber nutzbare Software mit der bis dahin entsprechend umgesetzten Funktionalität erhalten hat und andererseits der Auftragnehmer jeweils für die Leistungen der Sprints im Wesentlichen bezahlt wurde und keine massiven Skaleneffekte oder Vorleistungen für zukünftige Funktionalitäten erbracht hat, ist dieses Vorgehen für beide Seiten vorteilhaft und stellt eine der Grundlagen der Zusammenarbeit dar“. Dem entsprechen die vertraglichen Vereinbarungen, wonach sich die Teilabnahmen zu den jeweiligen Sprints auf „den Quellcode, die Funktionalität und die Dokumentation des gesamten Softwareinkrements“ beziehen. Dementsprechend waren die zu den jeweiligen Inkrementen erklärten Teilabnahmen als Erklärung des Klägers zu verstehen, dass das gelieferte Produktinkrement im Wesentlichen den in Anlage C aufgeführten Qualitätsstandards entspricht. Auf dieser Grundlage wäre es Sache des Klägers gewesen, Mängel der Software-Inkremente nach deren Abnahme mit den entsprechenden Mängelrechten gegenüber der Beklagten geltend zu machen. Dies gilt auch für solche Mängel, die die Weiterverwendbarkeit des Produkts beeinträchtigen.
Mit Hilfe dieser Mängelrechte (§ 634 BGB) hätte der Kläger die Möglichkeit gehabt, genau die vom Sachverständigen festgestellten Mängel der gelieferten Software gegenüber der Beklagten zu rügen und sie insoweit zur Nachbesserung aufzufordern, so das Gericht. Denn die Beklagte habe für jedes der gelieferten Teilprodukte nicht nur die Pflicht gehabt, eine lauffähige Software herzustellen, sondern diese auch zu testen und mit der vertraglich geschuldeten Dokumentation zu versehen. Ziel war es jeweils, ein vollständiges Produkt herzustellen, das der Kläger jederzeit einem Dritten zur weiteren Bearbeitung und Pflege hätte übergeben können. Dass dies ohne ausreichende Dokumentation nicht möglich ist, hat der Sachverständige in seinem Gutachten ausführlich dargelegt.
Diesbezügliche Mängelrügen hat der Kläger jedoch nie erhoben, die fehlende oder nur lückenhafte Dokumentation nie gerügt. Den erklärten Rücktritt hat der Kläger auf die nicht fristgerechte Herstellung im Zusammenhang mit anderen Mängeln (mangelnde Skalierbarkeit, mangelnde Barrierefreiheit und mangelnder Datenschutz) gestützt. Der Sachverständige konnte diese Mängel jedoch keinem der bereits erfolgten Sprints / Inkremente zuordnen. Vielmehr hätten diese Punkte nach Ansicht des Sachverständigen im Rahmen einer agilen Projektfortsetzung zum Gegenstand eines weiteren Sprints gemacht und ohne größeren technischen Aufwand behoben werden können. Erstmals im vorliegenden Rechtsstreit hat der Kläger mit der Klageschrift Mängel der Dokumentation gerügt. Dies geschah jedoch ohne ein entsprechendes Nachbesserungsverlangen und kann im Nachhinein nicht mehr zur Rechtfertigung der erklärten (Gesamt-)Kündigung herangezogen werden. Denn der Beklagten war insoweit nie Gelegenheit zur Nachbesserung hinsichtlich dieser Mängelrügen gegeben worden.
- Sichere Softwareentwicklung: Ein Leitfaden zur Risikovermeidung und Qualitätssteigerung - November 10, 2024
- Open Source AI Definition 1.0 - Oktober 31, 2024
- Überblick über das Softwarerecht in Deutschland: Wichtige rechtliche Probleme bei der Softwareentwicklung und -vermarktung - September 21, 2024
