Es gibt Entscheidungen, deren Aussagekraft darin liegt, eine notwendige Diskussion zu starten. Es ist aber zu befürchten, dass Rechtsanwälte die Entscheidung des LG Wiesbaden dazu verwenden werden zu behaupten, dass Scrum auf der Basis von Werkvertragsrecht funktionieren würde. Ich halte die Entscheidung für falsch, sie zeigt aber sehr schön, wie schwierig es ist, Projektmethodiken mit der Matrix des BGB und dem Denken von Juristen in Einklang zu bringen.
Sachverhalt: Die Parteien schlossen einen LOI. Der Hauptvertrag wurde nicht geschlossen. Im LOI wurden viele konkrete Ziele (Implementierung von Datenbanken, Businesslogik, Dokumentation) genannt und es wurde beschrieben, man wolle auf Scrum arbeiten. Das Projekt wurde vom Auftraggeber beendet und der Auftragnehmer verlangt die Vergütung von Leistungen wie Programmierungen und Beratungen.
Entscheidung des Gerichts: Das Gericht sagt, es sei ein Werkvertrag. Folge: § 649 I BGB kommt zur Anwendung und damit hat der Auftragnehmer Anspruch auf Ersatz der Aufwendungen.
Aussagen des Gerichts: Das Gericht hat Scrum als Werkvertrag beurteilt, weil ja der Kunde Productowner gewesen sei und der Auftragnehmer die technische Umsetzung schulde. Konzeptionshoheit des Auftraggebers auf der einen wie die Verpflichtung des Auftragnehmers auf der anderen Seite sei typisch für das Werkvertragsrecht.
Das ist so natürlich glatt falsch. Mit dieser Argumentation kann man jedes Angestelltenverhältnis dem Werkvertragsrecht unterstellen. Es geht nicht darum, dass der Kunde generell die Konzeptionshoheit hat, sondern darum dass der Kunde die Hoheit hat, die einmal gefasste Konzeption ändern zu können, in den Worten der IT: Regelmäßig Changes verlangen zu können.
Das würde bedeuten, dass das IT- Unternehmen sich auf ein nicht kalkulierbares Abenteuer einließe. Denn: Das Werkvertragsrecht besagt: Die vertraglich vereinbarte Beschaffenheit – also der Sollzustand der Software – wird einmal zwischen den Parteien festgelegt und dann nicht mehr geändert. Das Dienstvertragsrecht gibt dem Kunden die Hoheit der Konzeption und die Hoheit, die Konzeption jederzeit ändern zu dürfen – was typisch für Scrum ist –, aber entbindet das IT- Unternehmen von der Erfolgshaftung. Denn die Erfolgshaftung ist es, die das Werkvertrags- von dem Dienstvertragsrecht unterscheidet.
Die Entscheidung des LG ist schon deshalb grundverkehrt.
Ferner sind zwei Dinge zu berücksichtigen:
Da eine Erfolgshaftung nach dem Werkvertragsrecht besteht, müsste jeder Sprint ein für sich abnahmefähiges Werk zum Ziel und Ergebnis haben, wenn Scrum dem Werkvertragsrecht unterfiele. Und das ist genau nicht der Fall. Die Methodik soll durch Kommunikation und Kontrolle die Kundenzufriedenheit herstellen. Das geschieht genau nicht, in dem man zu Beginn eines Sprints mit endlosen Manntagen eine Dokumentation erstellt, die sich dann in der Regel doch wieder als lückenhaft herausstellt. Sie verzichtet auf diesen Schritt und setzt auf ständige Verbesserung durch Kommunikation und Kontrolle des erreichten Istzustandes. Durch diesen Schritt gewinnt man Zeit, spart Geld aber verzichtet als Auftraggeber auch auf eine Erfolgshaftung (den Erfolg ein Ziel erreicht zu haben, das man zum Zeitpunkt des Vertragsabschlusses nicht abschließend konkret beschreiben kann).
Wenn aber wie das LG Wiesbaden Scrum zu einem Werkvertrag machen will, müsste man die einzelnen Sprints auch nicht zu Teilen eines Werkvertrags machen, sondern jeweils getrennt abnahmefähig. Den Schritt will das LG aber nicht gehen. Es wäre auch nicht realisierbar, weil die Sprints eben nicht immer dazu führen, dass die Software dann wieder jeweils für sich betrachtet abnahmefähig wäre. Das wäre nur dann der Fall, wenn die Software jeweils „technisch und wirtschaftlich betrachtet isoliert abnahmefähig wäre“. Das ist sie aber nicht immer.
Und zweitens – eher eine juristische Thematik – stellt sich die Frage, was mit der Dokumentationspflicht ist. Die Bedienungsanleitung, die nach der Scrum- Methodik ja genau nicht wie selbstverständlich geschuldet ist, müsste für jeden Sprint nachgezogen werden. Im konkreten Fall wurde sogar von einem Sachverständigen moniert, dass eine übergeordnete Systemarchitektur fehle. Die kann es nach dem Vorgesagten auch gar nicht geben. Wenn der Auftraggeber das Ziel jederzeit ändern kann, wird eine übergeordnete Architektur nicht leicht zu erstellen sein.
Fazit: Wenn sich die Entscheidung des LG Wiesbaden durchsetzen sollte, wären die Vorteile von Scrum in Deutschland verloren. Zeit und Geschwindigkeit auf Kosten einer verminderten Kontrolle.
Wer Scrum auf Werkvertragsrecht abbilden will, muss wieder abnahmefähige Sprintlogs erstellen (bitte niemals gegen das Backlog abnehmen lassen, das man ja durch die Sprints konkretisieren will), was im Ergebnis Zeit und Geld kostet. Für jeden Sprint müssten Bedienungsanleitungen erstellt werden und die Software müsste nach jedem Sprint isoliert betrachtet werden. Man sieht: Da passt eines nicht zum anderen.
Stefan G. Kramer
