Scrum-Verträge: Herausforderungen und Lösungsansätze für die Vertragsgestaltung
Was ist SCRUM?
Es gibt verschiedene Modelle für agile Softwareentwicklung aber vor allem SCRUM etabliert sich immer mehr neben den traditionellen linearen Entwicklungsmethoden wie dem Wasserfallmodell. SCRUM bietet sowohl für die Auftraggeber als auch die Entwickler:innen viele Vorteile, vor allem, was Kosten und Erfolgsquote angeht. In der Vertragsgestaltung stellt sich der Umgang mit SCRUM aber eher als schwierig dar. Der Beitrag soll einige der Probleme bei SCRUM sowie Lösungsansätze und -ideen aufzeigen.
Um jedoch die Vorteile und die Probleme bei SCRUM zu verstehen, muss zunächst geklärt werden, was SCRUM überhaupt ist. Dem SCRUM-Modell liegt das Verständnis zugrunde, dass die Softwareentwicklung ein kompliziertes Unterfangen ist, dessen Umfang, mögliche Probleme und Störungen sich anfangs nicht absehen und planen lassen. SCRUM folgt einem iterativen und inkrementellen Ablauf. In jeder Iteration wird ein weiterer Ausbau des zuvor entwickelten Produkts vorgenommen. Diese Schleifen wiederholen sich so lange, bis das Projekt endgültig abgeschlossen und ein fertiges und funktionsfähiges Produkt entwickelt ist. Durch den iterativen Ablauf können innerhalb recht kurzer Zeit Probleme und Störungen identifiziert und darauf reagiert werden. Während die klassischen Entwicklungsmethoden (wie z.B. das Wasserfallmodell) aufgrund ihres sequenziellen und phasenbasierten Ablaufs unter langwierigen Prozessen und Entwicklungszyklen leiden, führt die iterative Arbeitsweise bei SCRUM zu kürzeren Entwicklungszyklen und früher zur Codeerstellung.
Wie funktioniert SCRUM?
Zu Beginn eines SCRUM-Projektes werden die vom Auftraggeber gewünschten Anforderungen an das Produkt in das Product Backlog (verwaltet durch den Product Owner) aufgenommen und nach Priorität sortiert. Im Rahmen der Sprint Planung, entscheidet das Entwicklungsteam in Rücksprache mit dem Product Owner, welche Anforderungen in einem zeitlich begrenzten Entwicklungsschritt, dem Sprint, umgesetzt werden. Diese Anforderungen werden sodann in das Sprint Backlog aufgenommen und der Sprint zeitnah gestartet. Während des Sprints arbeitet das Entwicklungsteam an der Umsetzung der Anforderungen und überprüft in täglichen Besprechungen, den Daily Scrums, die bisherigen Arbeitsergebnisse und bespricht das weitere Vorgehen der nächsten 24 Stunden. Nach Abschluss des Sprints stellt das Entwicklungsteam dem Product Owner die Arbeitsergebnisse des Sprints vor. Im Anschluss haben die Beteiligten in der Sprint Retrospektive die Möglichkeit, die eigene Arbeitsweise zu evaluieren und Verbesserungen auszuarbeiten. Die Sprint Retrospektive findet zeitlich zwischen der Sprint Review und der nächsten Sprint Planung statt. Mit den gewonnenen Erkenntnissen aus dem vorangegangenen Sprint beginnt der Prozess erneut und die nächsten Anforderungen aus dem Product Backlog werden im Rahmen der Sprint Planung in das Sprint Backlog aufgenommen und im Sprint umgesetzt. Dieser Zyklus wiederholt sich so lange bis das Projekt abgeschlossen ist.
Für das weitere Verständnis von SCRUM ist es wichtig, sich neben dem Prozessablauf auch mit den Rollen und Artefakten im SCRUM-Prozess vertraut zu machen, die benutzt werden, um den Entwicklungsprozess zu strukturieren. Dazu dient folgende kurze Übersicht zu den Begrifflichkeit bei SCRUM:
| Rollen bei SCRUM | SCRUM Artefakte | SCRUM Events |
| Product Owner: verwaltet das Product Backlog und ist verantwortlich für die fachlichen Anforderungen und die Priorisierung. | Product Backlog: ist eine Liste mit den gewünschten Anforderungen des Auftraggebers (veränderlich und unverbindlich) | Sprint: ist ein Zeitraum (i.d.R. 2-4 Wochen) innerhalb dessen ein fertiges, nutzbares und potenziell auslieferbares Produkt hergestellt wird. |
| Sprint: ist ein Zeitraum (i.d.R. 2-4 Wochen) innerhalb dessen ein fertiges, nutzbares und potenziell auslieferbares Produkt hergestellt wird. | Sprint Backlog: enthält die im jeweiligen Sprint umzusetzenden Anforderungen. Das Entwicklungsteam schätzt ein, welche Anforderungen im Sprint bewältigt werden können. | Sprint Planung: Planung und Festlegung dessen, welche Anforderungen im nächsten Sprint umgesetzt werden sollen. |
| Entwicklungsteam: ist ein Team aus Expert:innen, die dafür verantwortlich sind, das definierte Produkt zu entwickeln und auszuliefern. | User Story und Epics: eine User Story ist eine in Alltagssprache formulierte Softwareanwendung. Eine zusammenhängende Gruppe von User Stories werden Epic genannt. | Daily Scrum: kurzes, tägliches Meeting um die Arbeit der nächsten 24h zu besprechen und bisherige Arbeitsergebnisse zu überprüfen. |
| Sprint Review: Präsentation der implementierten Funktionen gegenüber dem Product Owner. | ||
| Sprint Retrospektive: bietet den Beteiligten die Möglichkeit sich selbst zu überprüfen. Findet zwischen dem Sprint Review und der Sprint Planung statt. | ||
| Definition of Done: definierte Feststellungskriterien, um ein einheitliches Verständnis herzustellen, wann ein Arbeitsergebnis als fertig anzusehen ist. |
Rechtsnatur von SCRUM-Verträgen
Das erste Problem bei der Vertragsgestaltung von SCRUM-Verträgen stellt sich bereits bei der Suche nach dem „richtigen“ Vertragstyp. In der Regel werden Softwareentwicklungsverträge, insbesondere solche die einer klassischen Entwicklungsmethode folgen, dem Werkvertragsrecht zugeordnet. Eine solch starre Einordnung eines agilen Softwareprojekts läuft jedoch der angestrebten Agilität entgegen. Zunächst entspricht die Risikoverteilung bei SCRUM-Projekten regelmäßig nicht der dem Werkvertragsrecht zugrundeliegenden Risikoverteilung. Bei klassischer Beauftragung trägt der Auftragnehmer allein das Fertigstellungsrisiko. Diese Verteilung wird der SCRUM-Methode nicht gerecht, denn dabei ist der Auftragnehmer auf die Mitwirkung des Auftraggebers angewiesen.
Im Rahmen eines SCRUM-Projektes ist das Erfolgs- und Fertigstellungsrisiko häufig auf beide Parteien aufgeteilt. Regelmäßig wird der Product Owner vom Auftraggeber bestellt, womit der Auftraggeber auch Kontrolle über das Product Backlog erhält. Über diese Rolle hat der Auftraggeber immensen Einfluss auf den konkreten Ablauf und die Durchführung des Projekts. Ob ein SCRUM-Projekt erfolgreich ist, liegt in den Händen beider Parteien. Ein weiterer Unterschied zu den klassischen Entwicklungsmethoden und deren Einteilung besteht darin, dass das Lasten- und Pflichtenheft der klassischen Entwicklungsmethoden nicht mit dem Product Backlog oder dem Sprint Backlog bei SCRUM vergleichbar ist. Diese Backlogs stellen im Gegensatz zu einem Lasten- und Pflichtenheft nur unverbindliche, jederzeit abänderbare Anforderungen dar. Sie sind nicht dazu geeignet – und auch nicht dazu gedacht – verbindliche Zielvereinbarungen für den Entwicklungsprozess zu enthalten.
Neben der Rollenverteilung spielt zudem der Umfang, die Tiefe und die Spezifikationen des Projekts eine große Rolle. Je detaillierter das Projekt und die einzelnen Anforderungen verbindlich spezifiziert sind, desto eher hat das Projekt werkvertraglichen Charakter. Demgegenüber spricht es eher für einen dienstvertraglichen Charakter, je geringer die Projektdetails konkretisiert wurden. Für den Auftragnehmer ist es in diesem Fall nur bedingt ersichtlich, welche Funktionen die Software haben soll und wie diese Funktionen ausgestaltet werden sollen. Die konkrete Ausgestaltung wird dann im Rahmen der Entwicklungstätigkeit in den Sprints herausgearbeitet.
Es sollte jedoch vermieden werden, bei SCRUM-Verträgen eine strikte Kategorisierung in Werk- oder Dienstvertrag vorzunehmen. SCRUM-Projekte enthalten Elemente, die beiden Vertragstypen zugeordnet werden können. Auf jeden Fall ist es nicht ratsam, das SCRUM-Projekt vorab, um einen gewählten Vertragstypus herum zu gestalten. Vielmehr sollte ausgehend vom Zweck des Projekts und der Projektdetails eine vertragliche Grundlage erstellt werden.
Aufgrund der diversen Faktoren, die Einfluss auf die Gestaltung und Ablauf des Projektes haben, ist es vorzugswürdig, sich nicht für einen Vertragstyp zu entscheiden, sondern die Vertragstypen zu kombinieren. Der Vertrag würde typischerweise sowohl dienstvertragliche als auch werkvertragliche Regelungen enthalten. Beispielsweise die Projektplanung, die Sprint Planung und weitere Punkte könnten dabei dienstvertraglicher Natur sein, während die konkrete Durchführung des Sprints sowie die Prüfung und Bewertung der Arbeitsergebnisse dem Werkvertragsrecht unterworfen werden. Der Vorteil dabei würde darin bestehen, dass die angestrebte Agilität über dienstvertragliche Regelungen umgesetzt werden kann, gleichzeitig jedoch mit einem (verbindlichem) Ziel verbunden ist, ein funktionsfähiges Werk zu erstellen und abzuliefern.
Abnahme der Arbeitsergebnisse
Die Abnahme des Werks hat auch bei IT-Projekten eine erhebliche Bedeutung und stellt regelmäßig einen Streitpunkt unter den Parteien dar. Denn die Abnahme kann, sofern das Werk nicht unter wesentlichen Mängeln leidet, nicht verweigert werden. Um Unstimmigkeiten darüber zu vermeiden, wann die Abnahme erklärt werden muss, sollten die Parteien Kriterien für Abnahme vereinbaren. Es besteht auch die Möglichkeit, Teilabnahmen für einzelne Produktinkremente zu vereinbaren. Aus rechtlicher Sicht wäre dies für beide Parteien zunächst von Vorteil. Sowohl Auftraggeber als auch Auftragnehmer würden Gewissheit darüber erlangen, ob die Produktinkremente funktionsfähig und den Erwartungen des Auftraggebers entsprechen. Faktisch besteht dabei jedoch insbesondere für den Auftraggeber das Problem, dass nicht jedes Produktinkrement oder Arbeitsergebnis am Ende eines Sprints abnahmefähig ist. Insbesondere bei den ersten Sprints des Projektes ist fraglich, ob die Ergebnisse abgenommen werden können. So lässt sich zum Beispiel zu Anfang eines Projekts, nicht bzw. nur erschwert beurteilen, wie und ob ein erzieltes Teilergebnis mit anderen Arbeitsabschnitten und dem Endergebnis zusammenspielen und funktionieren.
Man vollzieht hier eine Gratwanderung zwischen der für die Parteien nachvollziehbaren und durchaus wichtigen gewünschten Rechtssicherheit und der faktischen Ausgestaltung der Softwareentwicklung als agiles Projekt. Macht man zu sehr von der Möglichkeit von Teilabnahmen Gebrauch, droht man die Agilität des Projekts zu ersticken. Um die Spannung aus dieser Situation zu nehmen, bietet es sich an, Teilabnahmen zumindest für User Stories und Epics zu vereinbaren, sowie für weitere Produktinkremente, die der Auftraggeber zeitnah produktiv schalten möchte. Für die übrigen Sprints sollte (lediglich) geprüft werden, ob die erzielten Ergebnisse den festgelegte Akzeptanzkriterien entsprechen. Bestandteil des iterativen Prozesses kann sein, die Funktionsfähigkeit der Software zu testen. Der Auftraggeber bekommt so die Gelegenheit frühzeitig Fehlentwicklungen zu erkennen und zu intervenieren, indem er auf die Gestaltung des nächsten Sprints Einfluss nimmt.
Das könnte Sie auch interessieren:
- Software-as-a-Service und Recht – Ein Überblick
- dID-Richtlinie: Auswirkungen der neuen Regelungen im BGB auf das IT-Vertragsrecht
- Die datenschutzkonforme Implementierung von MS 365
Wenn alle Anforderungen aus dem Product Backlog abgearbeitet und umgesetzt sind sowie den Akzeptanzkriterien entsprechen, gilt es das Projekt als Ganzes abzunehmen. Hierbei kommt es einerseits auf die Funktionsfähigkeit und Interoperabilität der einzelnen Produktinkremente zueinander und andererseits auf die Gesamtfunktionalität der Software an. Auch bei der Gesamtabnahme sollten die Parteien Kriterien für Abnahme vereinbaren sowie die Übereinstimmung der vereinbarten Zieldefinition der Definition of Done prüfen.
Gewährleistungsrechte
Ähnliche Überlegungen sind bei der Inanspruchnahme von Gewährleistungsrechten anzustellen. Bei SCRUM-Projekten ist es dabei wichtig im Kopf zu behalten, dass nicht jeder Fehler bei der Umsetzung der Anforderungen unweigerlich auch einen Mangel darstellt. Vielmehr gilt bei SCRUM, dass nicht oder fehlerhaft umgesetzte Anforderungen zurück in das Sprint Backlog aufgenommen und in einem späteren Sprint erneut bearbeitet werden. Nicht jeder Fehler bedarf daher der Anwendung der Gewährleistungsrechte. Mit SCRUM geht ein für Gewährleistungsrechte unpassendes Verständnis von Fehlern einher. Eine fehlerhaft umgesetzte Anforderung aus dem Sprint Backlog, kann in einem der nächsten Sprints umgesetzt werden oder das Lernergebnis aus dem ersten Fehler führt dazu, dass die Anforderung gar nicht umgesetzt wird. Diese Arbeitsweise ist dem SCRUM-Prozess immanent und sollte nicht durch das Ausüben von Gewährleistungsrechten torpediert werden. Der Auftraggeber kann seinen Interessen an fehlerarmen Entwicklungsprozessen dadurch gerecht werden, dass er sich aktiv in den Entwicklungsprozess einbringt.
Davon zu unterscheiden ist das Vorliegen tatsächlicher Mängel, also Programmier- und Entwicklungsfehler, die sich nach Abschluss des Entwicklungsprozesses auf die Funktionsweise der Software auswirken. Für diese Art von Fehlern ist die Ausübung von Gewährleistungsrechten sinnvoll.
Vergütung und Exit
Bei der Vergütung muss ebenfalls mitgedacht werden, dass sich ein agiles Projekt in der Rollen- und Risikoverteilung von klassisch linearer Vorgehensweise unterscheidet. Die Vereinbarung eines Festpreises oder Vergütung anhand von Milestones ist zwar grundsätzlich möglich, birgt aber das Risiko des „agile washing“. Entsprechende Vergütungsvereinbarungen können nur schwer die Realität des Entwicklungsprojektes abbilden. Bei einem SCRUM-Projekt wird man zu Beginn keine vernünftigen Milestones definieren können oder zumindest den Aufwand bis zu deren Erreichen nicht vernünftig abschätzen können. Und auch ein Festpreis führt tendenziell dazu, dass der im SCRUM-Projekt tatsächlich anfallende Aufwand nicht angemessen in der Vergütung abgebildet werden kann, denn zu Beginn des Projekts ist der Aufwand noch gar nicht wirklich absehbar.
Das Ergebnis eines Entwicklungsvorgangs nach SCRUM kann auch sein, dass das Projekt abgebrochen werden muss. Gründe dafür können vielfältig sein; von mangelnder Kooperationsfähigkeit des Teams bis zu der Erkenntnis, dass sich die Anforderungen des Backlogs nicht umsetzen lassen. Vertragsregelungen zum Exit-Management müssen dies widerspiegeln und es den Vertragsparteien erlauben, das Projekt an geeigneter Stelle abzubrechen – oder gegebenenfalls den Zwischenstand an ein anderes Projektteam zu geben, damit weiterentwickelt werden kann.
Fazit
SCRUM-Verträge sind in der Vertragsgestaltung ein schwieriges Thema. Wer ein Entwicklungsprojekt mit SCRUM umsetzen möchte, beabsichtigt die Vorteile der damit einhergehenden Agilität in Kosten und Erfolgschancen zu nutzen. Damit die angestrebte Agilität auf vertraglicher Ebene gebührend berücksichtigt und umgesetzt wird, ist es erforderlich, dass ein starres Schubladendenken vermieden wird. Die Vertragsgestaltung muss die Struktur des SCRUM-Projektes abbilden, ohne die Agilität zu ersticken. Das ist nur möglich, wenn sich das ganze Projektteam auf das Konzept SCRUM einlässt, und jeder beteiligte sich aktiv und kooperativ einbringt. Es bedarf Zugeständnissen auf rechtlicher und faktischer Ebene von beiden Parteien, um auch wirklich ein Projekt agil durchzuführen und nicht nur ein Projekt durchzuführen, das man „agil“ nennt. Damit all das im Vertrag sinnvoll abgebildet werden kann, braucht es Fingerspitzengefühl und ein Verständnis für das konkrete Entwicklungsprojekt.