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 Software- herstellungsverträ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ütungsmodellen der Scrum-Methode im Fokus des Interesses.
Werk- oder Dienstvertrag im Scrum?
Bei der Methode mit Scrum sind die vereinbarten Inhalte entscheidend dafür, ob vorwiegend von einen Dienstvertrag oder einen 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 Owners übernehmen und die zentrale Steuerung des Projektes nicht mehr beim Auftragnehmer liegen, geht man vorwiegend von einem Dienstvertrag aus.
Eine klare Einordnung als Werkvertrag ist auch nur schwer möglich. Denn bei Vertragsschluss stehen 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 bei- spielhaft 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 Bedeu- tung: Er definiert die Produktanforderungen – gerade auch vor dem Hintergrund der vorhan- denen 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 Gesichts- punkten 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 ein- her, um genau solche Änderungen in der Priorisierung, Zieldefinition und Budgetierung an- stoß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ück- zugreifen, 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 erfor- dert 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 vie- le 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 be- sonders 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. Bestim- mungen zum Zeitpunkt der Rechtseinräumung fehlen meist ganz. Versäumnisse in der Ver- tragsgestaltung 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 Beson- derheit agiler Softwareprogrammierung liegt darin, dass es sich um eine individuelle Pro- grammierung handelt und Nutzungsrechte bereits an Teilergebnissen entstehen können.
Daher ist es wichtig, eine Abgrenzung vorzunehmen und den exakten Zeitpunkt der Rechts- einrä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.
Autorin:
RA Simone Rosenthal, Schürmann Wolschendorf Dreyer Rechtsanwälte
