In einer von Daten getriebenen Welt müssen gerade Softwareprojekte in der Entwicklungsphase nah am Puls der Zeit realisiert werden. Die Anforderungen und Projektziele der Kunden ändern sich schnell. Technologien beweisen sich in einem Projekt oder scheitern. In den Augen viele Softwareentwickler können klassische Projektmethoden wie z.B. das Wasserfallmodell diesen Anforderungen nicht mehr gerecht werden. Agile Projektmethoden wie z.B. Scrum, Kaban oder Crystal tragen diesem Umstand Rechnung.

Nachfolgend sollen am Beispiel von Scrum gängige rechtliche Problemstellungen besprochen werden.

Was ist Scrum?

Da in diesem Beitrag die rechtlichen Aspekte im Rahmen von agiler Softwareentwicklung im Vordergrund stehen, möchte ich mich an dieser Stelle kurzfassen. Als eine der populärsten agilen Projektmethode greift Scrum auf einen iterativen, inkrementellen Ansatz zurück, um die Entwicklung komplexer Projekte zu begleiten.

Zu Beginn eines Projekts wird das Product Backlog erstellt, dass die bis dahin bekannten Projektanforderungen beinhaltet. Das Product Backlog ist dabei jedoch nicht abschließend und wird fortlaufend durch die Projektbeteiligten aktualisiert.

Aus dem Product Backlog werden in einem nächsten Schritt die sogenannten Sprint Backlogs erstellt. Sie bilden die Grundlage für den einzelnen Sprint und bestehen aus einer Liste von ausgewählten Product Backlog-Einträgen und einem entsprechenden Zeitplan.

Die Vorgaben des Sprint Backlogs werden dann in einem Sprint umgesetzt. Dabei ist jedoch zu beachten, dass der Sprint Backlog während des Sprints von dem Entwicklungsteam auch angepasst wird. Erforderliche Arbeiten werden hinzugefügt und unnötige Arbeiten aus dem Backlog entfernt. Während der Sprints wird der Projektverlauf durch innerhalb eines Daily Scrum synchronisiert bis der Sprint abgeschlossen ist.

Am Ende eines Sprints wird ein Sprint Review abgehalten. Hieran nehmen alle beteiligten Personen teil. Zusammen werden in dieser Phase die Ergebnisse des vergangenen Sprints überprüft. Der Status des gesamten Projekts wird überdacht und das Product Backlog gegebenenfalls angepasst.

Letztlich wird im Rahmen der Sprint Retrospective ein Blick auf den vergangenen Sprint geworfen. Die Beteiligten besprechen hierbei die guten und schlechten Ereignisse, identifizieren die Gründe und legen Verbesserungen für die kommenden Sprints fest.

Anschließend beginnt der Prozess wieder mit der Erstellung eines Sprint Backlogs bis alle Anforderungen aus dem Product Backlog abgearbeitet wurden.

In der Gesamtschau ergibt sich dann der folgende Scrum-Prozess:

Kurz und anschaulich wird diese Methode auch in dem nachfolgenden Video der Scrum Alliance erklärt:

Urteil des Landgericht Wiesbaden:

Für das Fachpublikum sind die juristischen Diskussionen, um die Probleme agiler Softwareentwicklung nichts Neues. Im Grundsatz geht es hier um die Frage, ob Verträge über agile Projektmethoden nach Dienst- oder Werkvertragsrecht zu bewerten sind. Je nachdem zu welchem Ergebnis man gelangt, hat die Einordnung Auswirkung auf bedeutende Regelungen, wie die Vergütung oder aber die Mängelrechte. Beides Punkte über die beteiligten Projektparteien gerne streiten.

Umso interessanter ist das Urteil des LG Wiesbaden vom 30.11.2016 (Az. 11 O 10/15), dass sich als eines der ersten Gerichte in Deutschland mit dieser Thematik zu beschäftigen hatte. Was war passiert? Die Streitparteien haben in einem Letter of Intent (LOI) festgehalten eine Internetplattform zu entwickeln. Scrum wurde dabei als einschlägige Projektmethode festgelegt. Ein darüber hinausgehendes Vertragswerk haben die Parteien nicht geschlossen, so dass sich nach Scheitern des Projektes über die Vergütung von Programmier- und Beratungsleistungen gestritten wurde.

Die zuständige Kammer versagte der Klägerin den geltend gemachten Vergütungsanspruch. In den Augen der Richter handele es sich bei dem Vertragsverhältnis auf Basis des LOI, um einen klassischen Werkvertrag. Charakteristisch für diesen sei die Planungsphase eines Projektes. Auf diese Planungsphase werde im Rahmen der agilen Softwareentwicklung nach Scrum nicht verzichtet. Vielmehr sei dieses Planungselement im Projektfluss integriert und steht einer Einordnung als Werkvertrag nicht entgegen. Zudem sei es auch bei agilen Projektmethoden der Fall, dass der Auftraggeber regelmäßig die Projekthoheit innehat und dem Auftragnehmer die Ausführungs- und Dokumentationspflicht zukommt.

Hat das Folgen für den Vertrag?

Nein, mit dem Entscheidung ist kein Präzedenzfall geschaffen. Schließlich fällt bei Betrachtung des Sachverhalts direkt auf, dass die Parteien keinen ausführlichen Vertrag geschlossen haben, sondern nur einen LOI. Dementsprechend wurden die Möglichkeiten der Vertragsgestaltung von den Parteien nicht vollends ausgeschöpft. Dabei gibt es – wie nachfolgend dargestellt – im Rahmen der Projektverträge Stellschrauben über die auf die Einordnung des Vertrages Einfluss genommen werden kann:

Vertragsgegenstand

Die Vertragsparteien sollten gleich zu Beginn des Vertrags klar zum Ausdruck bringen, dass eine agile Methode, z.B. Scrum zum Einsatz kommt. Die Methode sollte sodann ausführlich in einem Anhang dargestellt und erörtert werden. Auch sollten die initialen Projektanforderungen, die beide Parteien im Product Backlog festhalten ebenfalls als Anhang beigefügt werden.

Projektverantwortung

Scrum führt dazu, dass die Verantwortung für das Projekt auf beiden Schultern verteilt ist. Eine Einordnung zum Dienstvertrag würde jedoch erfordern, dass die Verantwortung vollumfänglich auf den Schultern des Kunden und Auftraggeber lastet. Ihm wären damit alle bedeutenden Projektpositionen, wie dem Product Owner und Scrum Master zuzuordnen. Ob dies für ein Projekt tragbar ist, hängt zum einen sicherlich von den beteiligten Personen und dem entsprechenden Projekt ab.

Neben den typischen Scrum-Rollen ist auch zu überlegen, ob man nicht auch ein weiteres unabhängiges Entscheidungsgremium in den Prozess integriert. Aufflammende Konflikte können hier mit der notwendigen Distanz besprochen werden, sollten aber nicht den eigentlichen SCRUM-Prozess torpedieren.

Dokumentation

Auch ein Projektvorgehen nach Scrum verlangt von dem Softwarehersteller, dass eine Dokumentation erstellt werden muss. Über die Formalien, den Umfang und Fälligkeit der Dokumentation sollten sich die Parteien abstimmen. Ausgehend von einer minderen Komplexität der Software könnten sich die Parteien an dieser Stelle sogar lediglich auf eine ausreichende Kommentierung des Source-Codes einigen.

Vergütung

Im Rahmen der Vergütungsregelungen gibt es bei agilen Projektverträgen eine Vielzahl von Gestaltungsmöglichkeiten. Häufig werden vertraglich Budgets für die einzelnen Sprints vereinbart. Dieser Umstand streitet im Regelfall für die Einordnung zu einem Werkvertrag, da die Vergütung oft auch an eine Abnahme oder Freigabe geknüpft ist. Bei einer Abrechnungspraxis nach tatsächlich angefallenem (Zeit-)Aufwand ist hingegen eher von einem Dienstvertrag auszugehen.

Fazit:

Sofern agile Prozessmethoden Ihren Berufsalltag berühren, sollten Sie sich auch mit den gängigen „Baustellen“ auseinandersetzen und im Rahmen der Vertragsgestaltung berücksichtigen. Oft lassen sich hierdurch bereits frühzeitig Risiken erkennen und beherrschen.

Brauchen Sie Unterstützung bei der Erstellung agiler Projektverträge oder stellen sich ihrerseits weitere Fragen? Gerne können Sie sich per Kontaktformular, XING-Profil oder per Telefon an mich wenden.