Agile Softwareprojekte in der Vertragsgestaltung

Agile Projektmethoden sind nicht mehr wegzudenken. Sie ermöglichen, selbst große Projekte durchzuführen, bei denen der Leistungsumfang nicht von Beginn an feststeht und ein ständiges Abstimmen mit dem Auftraggeber stattfinden kann. Sowohl in der praktischen Durchführung als auch in der rechtlichen Bewertung verlangen agile Vorgehensweisen neue Ansätze.

Architektur/Methoden  –  9 Kommentare
Agile Softwareprojekte in der Vertragsgestaltung

Es gibt verschiedene Methoden, wie sich IT-Projekte abwickeln lassen. Bei der Wasserfallmethode liegt vor Beginn des Projekts die fachliche Spezifikation als Lastenheft vor. Das Heft wird dabei als Grundlage für den IT-Projektvertrag genommen. Bei agilen Projektmethoden wie Scrum, Kanban, Crystal oder Extreme Programming hingegen erarbeiten die Projektmitglieder die Anforderungen des Auftraggebers an die jeweilige Software gemeinsam in kleinen Schritten.

Fehlende Vertragswerke

Nach einer Studie der deutschen Gesellschaft für Projektmanagement und der Hochschule Koblenz aus dem Jahr 2015 ist Scrum die meistgenutzte agile Methode und wird gegenüber anderen Methoden regelmäßig besser bewertet, sodass sie auch hier exemplarisch herangezogen wird.

Ziel von Scrum ist es, dass Auftraggeber zeitnah eine Software erhalten, die ihren spezifischen Anforderungen entspricht. Bei der 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 Manager vor allem in traditionellen Industrien vor dieser Projektmanagementmethode zurückschrecken. Denn die komplexen Projekte und die unabhängigen Entwicklungsphasen bringen rechtliche Besonderheiten in den Softwareherstellungsverträgen mit sich.

Bei Scrum stellen sich unter anderem die folgenden Fragen:

  • Wie lassen sich isolierte Werkverträge auf einzelne Sprints anwenden und ins Sprint Backlog integrieren, ohne zu behindern?
  • Gibt es Kündigungsmöglichkeiten/Exit-Strategien?
  • Wie kann man Unklarheiten bezüglich der Leistungserbringung in den einzelnen Sprints effektiv entgegenwirken, 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 in Scrum?

Bei Scrum sind die vereinbarten Inhalte entscheidend dafür, ob vorwiegend von einem Dienst- oder einem Werkvertrag auszugehen ist. Die projektbezogene Zusammenarbeit und die starke Mitwirkung des Auftraggebers könnten eher für einen Dienstvertrag sprechen. Sollte der Auftraggeber zum Beispiel die Rolle des Product Owner übernehmen und die zentrale Steuerung des Projekts nicht mehr beim Auftragnehmer liegen, geht man vorwiegend von einem Dienstvertrag aus.

Eine klare Einordnung als Werkvertrag ist nur schwer möglich. Denn bei Vertragsschluss stehen die Eigenschaften der Software noch nicht konkret fest. Eine Beschaffenheits- oder Vergütungsvereinbarung, die von Anfang an vorliegt, gibt es meistens nicht beziehungsweise ist schwer zu realisieren. Trotzdem: Für die vertragsrechtliche Einordnung sollte man sich vor Augen halten, dass nach der Rechtsprechung ein werkvertraglicher Erfolg bereits in der ordnungsgemäßen Durchführung von Untersuchungen oder der Anfertigung von Berichten liegen kann.

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

Es erscheint daher sinnvoll, die einzelnen 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. Die Werkverträge können Bestandteile eines Rahmenvertrags 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" – mit durchschlagender Auswirkung auf den Grundkatalog des Product Backlog. Denn es soll sich mit seiner Übersicht über alle Elemente des zu entwickelnden Produkts gerade dadurch als besonders zielführend erweisen, dass es keinen Anspruch auf eine vollständige Durchplanung der 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.