21.05.2019 | Informationstechnologie

Agile Softwareprojekte in der Vertragsgestaltung: Herausforderungen

IT-Projekte

In der Softwareentwicklung gewinnen die agilen Projektmethoden mehr und mehr an Bedeutung. Agile Methoden ermöglichen vor allem große Projekte durchzuführen, bei denen der Leistungsumfang nicht von Beginn an feststeht und ein ständiges Abstimmen mit dem Auftraggeber stattfinden kann.

Es gibt verschiedene Methoden, wie IT-Projekte abgewickelt werden können – bei der weit verbreiteten herkömmlichen Wasserfallmethode liegt vor Beginn des Projektes die fachliche Spezifikation als Lastenheft vor. Das Lastenheft wird dabei als Grundlage für den IT-Projektvertrag genommen. Bei den agilen Projektmethoden wie etwa Scrum, Kanban, Agiles Datawarehousing, Crystal oder Extreme Programmierung hingegen werden die Anforderungen des Auftraggebers an die jeweilige Software gemeinsam in kleinen Schritten im Projekt erarbeitet.

Softwareentwicklungsmethode Scrum

Ziel der weit verbreiteten agilen Softwareentwicklungsmethode Scrum ist es, dass der Auftraggeber zeitnah eine Software erhält, die seinen spezifischen Anforderungen entspricht. Bei dieser neuen Methode geht es vor allem um die zu erreichenden Projektziele. Die unsichere Rechtslage und fehlende Vertragswerke bei agilen Softwareentwicklungen erschweren jedoch zuweilen das Arbeiten mit Scrum und lassen viele Manager noch vor dieser Arbeitsweise zurückschrecken. Denn die komplexen Projekte und die unabhängigen Entwicklungsphasen bringen rechtliche Besonderheiten in den Softwareherstellungsverträgen mit sich.

Bei der Scrum-Methode stellen sich unter anderem die folgenden Fragen: Wie können isolierte Werkverträge auf einzelne Sprints angewandt und ins Sprint Backlog integriert werden ohne zu behindern? Gibt es Kündigungsmöglichkeiten/Exitstrategien? Wie kann Unklarheiten bezüglich der Leistungserbringung in den einzelnen Sprints effektiv entgegengewirkt werden, um für einen reibungslosen und sicheren Ablauf zu sorgen? Ebenso stehen die Vergütungsmodelle der Scrum-Methode im Fokus des Interesses.

Werk- oder Dienstvertrag im Scrum?

Die Frage nach der Vertragstypologie von agilen Entwicklungsverträgen ist eines der juristischen Kernprobleme agiler Softwareprojekte. Die Einordnung kann gravierende Folgen auf das Vertragsverhältnis haben, wie sich aus dem folgenden Überblick ergibt.

Dienstvertrag Werkvertrag 
Nur die Leistung, kein Erfolg geschuldet (z.B. Beratervertrag)Erfolg wird geschuldet, mangelfreies Werk (z.B. Bauvorhaben)
Keine Gewährleistungsrechte/keine AbnahmeGewährleistungsrechte /Abnahme
Kurzfristige KündigungsrechteKaum gesetzliche Kündigungsmöglichkeiten
weisungsgebundennicht weisungsgebunden
Honoraranspruch auch bei mangelhafter Leistung

 

So ist es nicht verwunderlich, dass sich die Gerichte in den zum Zeitpunkt einzig einschlägigen Urteilen zu SCRUM mit der Einordnungsfrage beschäftigt haben.

Bereits das LG Wiesbaden hielt in seinem Urteil vom 30.11.2016 fest, dass es zur Einordnung auf den im Vertrag zum Ausdruck kommenden Willen der Vertragsparteien ankommt. In dem zugrundeliegenden Fall hätten demnach die Parteien das Vertragsverhältnis dem Werkvertragsrecht unterstellt. So wurden Abnahmekriterien festgelegt und innerhalb der Sprints genau die zu erledigenden Aufgaben und deren Umfang bestimmt. Das Gericht zog daraus den Schluss, dass die Parteien nicht bloß die Leistung als solche, sondern einen konkreten Erfolg als geschuldet vereinbaren wollten. Dagegen spräche weder, dass auf eine vorherige Planungsphase und ein entsprechendes Pflichtenheft verzichtet wurde, noch, dass die Vergütung nach Zeitaufwand berechnet wurde.

Das OLG Frankfurt (mit Urteil vom 17.08.2017), dass als Folgeinstanz in derselben Streitsache entschied, entzog sich zwar einer abschließenden Einordnung des Vertrages, hielt aber fest, dass eine Auslegung zumindest auf die teilweise Anwendung von Werkvertragsrecht schließen lassen könnte. Insofern bestätigte das OLG Frankfurt mit seiner Entscheidung, dass es für die Einordnung auf eine dezidierte Vertragsgestaltung ankommt und die Annahme eines gemischten Vertrages mit Dienst- und Werkvertragselementen nicht fern liegt.

Eine klare Einordnung als Werkvertrag ist auch nur schwer möglich. Für einen Dienstvertrag könnten beispielsweise die projektbezogene Zusammenarbeit und die starke Mitwirkung des Auftraggebers sprechen. Sollte der Auftraggeber die Rolle des Product Owners übernehmen und die zentrale Steuerung des Projektes nicht mehr beim Auftragnehmer liegen, ist wohl vorwiegend von einem Dienstvertrag auszugehen. Darüber hinaus stehen bei Vertragsschluss die Eigenschaften der Software noch nicht konkret fest. Eine Beschaffenheitsvereinbarung oder Vergütungsvereinbarung, die von Anfang an vorliegt, gibt es meistens nicht bzw. ist schwer möglich. Trotzdem: Für die vertragsrechtliche Einordnung sollte man sich vor Augen halten, dass nach der Rechtsprechung ein werkvertraglicher Erfolg auch bereits in der ordnungsgemäßen Durchführung von Untersuchungen oder der Anfertigung von Berichten liegen kann.

Es erscheint daher sinnvoll, die einzelne „Sprints“ als isolierte Werkverträge anzusehen. Dafür wäre es notwendig, dass ein Teilerfolg im Rahmen des Sprint Planning Meeting definiert und dieser Teilerfolg im Sprint Backlog dokumentiert wird, um die Risiken angemessen zu verteilen und Rechtssicherheit zu schaffen. Diese Werkverträge können Bestandteile eines Rahmenvertrages werden, der wiederum allgemeine Regelungen wie Vergütung, Haftung oder Exit-Möglichkeiten enthält.

Zu vermeiden ist allerdings, dass das Sprint Backlog in ein Lasten- und Pflichtenheft „mutiert“ wird – mit durchschlagender Auswirkung auf den Grundkatalog des Product Backlog. Denn das Product Backlog mit seiner Übersicht über alle Elemente des zu entwickelnden Produkts soll sich gerade dadurch als besonders zielführend erweisen, dass es keinen Anspruch auf eine vollständige Durchplanung dieser Elemente nach klassischem Verständnis formuliert, sondern lediglich eine Richtungsweisung für die Ausgangsschätzung der Anforderungen gibt. Hauptcharakteristikum ist seine Dynamik, was es vom klassischen Lasten- oder Pflichtenheft unterscheidet.

Was sollte bei den Rahmenverträgen beachtet werden?

Die Rahmenverträge sind in der Regel umfangreiche Vertragswerke. Hier werden nur beispielhaft einige regelungsbedürftige Punkte angesprochen.

Qualifikationen/Product Owner

Wichtig in den agilen Rahmenverträgen ist, dass die Vertragsparteien sich auf ihre jeweiligen Qualifikationen verständigen. Die Rolle des Product Owner erhält dabei besondere Bedeutung: Er definiert die Produktanforderungen – gerade auch vor dem Hintergrund der vorhandenen Budgets – und ihm fällt die Verantwortung für Inhalt und Einsatz des zu entwickelnden Systems zu. Er sollte von den Vertragsparteien nach strengsten qualifikatorischen Gesichtspunkten ausgewählt und mit den zugehörigen Kompetenzen versehen werden. Denn nur so kann der Product Owner genau beurteilen, ob die Leistungserbringung den planerischen Grundvorgaben entsprechend zielführend ist. Damit gehen auch Weisungsbefugnisse einher, um genau solche Änderungen in der Priorisierung, Zieldefinition und Budgetierung anstoßen und umsetzen zu können. Haben sich die Vertragsparteien auf die Person und/oder die Qualifikation des Product Owners geeinigt, sollte dies vertraglich festgehalten werden.

Agile Vergütungsregelungen

Bei den Agilen Verträgen bietet es sich an, auch auf alternative Vergütungsmodelle zurückzugreifen, die das Risiko auf beide Parteien ausgewogen verteilen (z.B. Function-Point-Methode). Auch die Definition von Vergütungen für einzelne Sprints ist möglich – dies erfordert jedoch viel Vertrauen der Vertragsparteien, da die Anzahl der Sprint zu Beginn oft nicht feststeht.

Soweit inhaltliche Anforderungen an das Projektergebnis zu Beginn der Zusammenarbeit grob vereinbart werden, können die Parteien zugleich eine Einigung darüber treffen, wie viele Entwicklungszyklen sie für die Umsetzung erwarten, wie viel Zeit hierfür voraussichtlich benötigt wird und welche Kosten geschätzt anfallen – hier ist jedoch Vorsicht angebracht, damit nicht nur die vertragliche Gestaltung Agilität verloren geht. Bei der Vergütung ist besonders wichtig eine für das Projekt passende Vertragsgestaltung zu wählen.

Schadensersatz/Nutzungsrechte

Der Frage der Einräumung von Nutzungsrechten wird oft eine untergeordnete Bedeutung beigemessen und entsprechende Vertragsklauseln sind häufig zu ungenau gefasst. Bestimmungen zum Zeitpunkt der Rechtseinräumung fehlen meist ganz. Versäumnisse in der Vertragsgestaltung diesbezüglich gehen zu Lasten des Auftraggebers. Er trägt die Beweislast dafür, dass die von ihm behauptete Rechtseinräumung vom Vertrag gedeckt ist. Die Besonderheit agiler Softwareprogrammierung liegt darin, dass es sich um eine individuelle Programmierung handelt und Nutzungsrechte bereits an Teilergebnissen entstehen können. Daher ist es wichtig, eine Abgrenzung vorzunehmen und den exakten Zeitpunkt der Rechtseinräumung sowie deren Umfang festzulegen.

Darüber hinaus sind natürlich – wie in klassischen Softwareverträgen – einzelfallbezogene Klauseln zu empfehlen.

In vielen Unternehmen werden die agilen Prozessmethoden in der Zukunft zum festen betrieblichen Alltag gehören. Daher wird es immer wichtiger, dass Unternehmen gute Lösungen zur vertraglichen Abwicklung innerhalb der agilen Prozessmethoden entwickeln.

Für Rückfragen stehen Ihnen die Rechtsanwälte von Schürmann Rosenthal Dreyer sehr gerne zur Verfügung.


Hinterlassen Sie einen Kommentar


Weitere Artikel

Anwälte der Kanzlei empfohlen durch: