Agile Methoden zur Softwareentwicklung erfreuen sich großer Beliebtheit – im Konfliktfall ergeben sich jedoch oft rechtliche Probleme, die vermeidbar sind.
Eine agile Vorgehensweise bei der Entwicklung von Software läuft der klassischen „Wasserfallmethode” in der Praxis immer mehr den Rang ab. Laut dem bereits vor knapp 20 Jahren entwickelten „Manifest für agile Softwareentwicklung“ basiert dieser Ansatz auf folgenden Prinzipien:
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge
- Funktionierende Software mehr als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
- Reagieren auf Veränderung mehr als das Befolgen eines Plans
Hinter diesem „Agilen Manifest“ stehen zwölf Prinzipien, die als theoretische Grundlage für agile Entwicklungsmethoden dienen. Zu den Prinzipien zählen unter anderem Kundenzufriedenheit, gemeinsame Reflektion im Team, technische Exzellenz und ständige Verbesserung der Effektivität.
Trotz des folkloristisch anmutenden Manifests – die rechtlichen Probleme agiler Softwareentwicklung sind sehr praxisrelevant und Konflikte treten mit großer Regelmäßigkeit zutage. Um dem vorzubeugen, sollte das agile Softwareprojekt durch vorausschauende Projektplanung und Vertragsgestaltung abgesichert werden.
„Wasserfall“ als Auslaufmodell?
Für die traditionell sequentielle Vorgehensweise bei Softwareentwicklungsverträgen wird häufig die Metapher eines Wasserfalls bemüht. Damit soll zum Ausdruck gebracht werden, dass ein Projekt in größeren, aufeinander folgenden und aufbauenden Zyklen verläuft. Typischerweise gibt es vier bis fünf Projektphasen: von der Bedarfsanalyse, über Softwaredesign und Programmierung bis hin zur Testphase und Abnahme des fertigen Produkts. Grundannahme dieser sog. Wasserfallmethode ist, dass ein Zyklus komplett abgeschlossen werden kann, bevor mit dem nächsten begonnen wird.
Dieser Ansatz ist jedoch praktisch häufig nicht umsetzbar und verursacht unnötige Kosten. So kann es beispielsweise effizienter sein, fertig programmierte Bestandteile bereits zu testen, während an anderer Stelle noch programmiert wird oder mit dem Design für Programmteil A zu beginnen, während für Programmteil B noch Bedarfe ausgelotet werden. Zudem können sich im Laufe der oft monate- oder gar jahrelangen Projektphase neue Anforderungen des Kunden ergeben, die bei einem Wasserfall dazu führen würden, dass ganze Zyklen wiederholt werden müssen.
Die Wasserfallmethode verlangt von den Parteien, dass die gesamten Projektanforderungen von vornherein z.B. durch die Erstellung eines Lastenhefts konkretisiert werden. Dieser starre Ansatz hat den Nachteil, dass Anpassungen umständlich über ein Change-Request Verfahren zwischen den Parteien ausgehandelt werden müssen. Dies ist sowohl zeitaufwendig als auch kostenintensiv. Insofern ist es nicht verwunderlich, dass bei der Softwareentwicklung immer häufiger auf agile Methoden gesetzt wird und der Wasserfall immer seltener zum Einsatz kommt.
Ein wesentlicher Vorteil des Wasserfalls ist jedoch, dass diese Methode ein relativ hohes Maß an Planungssicherheit bietet. Sofern die einzelnen Zyklen von vornherein definiert werden können, bietet das sequentielle Vorgehen somit nach wie vor eine veritable Alternative, die zu einem erfolgreichen Projektverlauf führen kann. Dieser Ansatz ist zwar mit höherem Planungsaufwand verbunden, jedoch sollten die Parteien davor nicht per se zurückschrecken.
Grundzüge agilen Projektvorgehens
Wie bereits im Agilen Manifest formuliert, spielen bei agilen Projektansätzen Interaktion, Zielorientierung und das Reagieren auf Veränderungen eine zentrale Rolle. Nicht sequentiell, sondern iterativ, d.h. in vielen kleinen, flexiblen, zum Teil parallel ablaufenden Projektzyklen (sog. „Sprints“) soll prozessual den Problemen begegnet werden, die im Laufe der Softwareentwicklung auftreten können.
Jeder Sprint umfasst die selbständige Entwicklung von Design, Programmierung und eine abschließende Testphase binnen eines kurzen Zeitraums von üblicherweise zwei bis vier Wochen. Die Sprints bauen aufeinander dergestalt auf, dass zunächst Grundfunktionalitäten und anschließend individuelle Anforderungen („Komfortfunktionalitäten“) umgesetzt werden. Dieses Prinzip lässt sich sowohl bei der Entwicklung von Individualsoftware als auch im Rahmen der Anpassung und Implementierung von Standardsoftware anwenden.
Ein oft auftretendes Symptom der agilen Softwareentwicklung ist, dass die initiale Leistungsbeschreibung nur grob umrissen wird. Dies wird häufig damit begründet, dass sich die konkrete inhaltliche Ausgestaltung der einzelnen Sprints erst im Projektverlauf ergebe. Dieses Plus an Flexibilität wird jedoch mit einem Minus an Planungssicherheit bezahlt – sowohl in zeitlicher als auch finanzieller Hinsicht. Häufig müssen daher Projektbudgets nach oben korrigiert und Go-Live Termine nach hinten verschoben werden.
Alles „Scrum“, oder was?
Die bekannteste agile Projektmethode ist der sog. „Scrum“. Der Scrum (zu Deutsch etwa „Gedränge“) wird laut offiziellem Scrum-Guide wie folgt definiert:
Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern.
Des Weiteren heißt es dort:
Scrum ist weder ein Prozess, noch eine Technik oder vollständige Methode. Vielmehr ist es ein Rahmenwerk, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. (…). Das Scrum-Rahmenwerk besteht aus Scrum‑Teams und den zu ihnen gehörenden Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente innerhalb des Rahmenwerks dient einem bestimmten Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg.
Theoretisch basiert Scrum auf den Säulen Transparenz, Überprüfung und Anpassung. Ein typisches Scrum-Team setzt sich wie folgt zusammen:
- Product Owner: Verantwortlich für das Management des Product Backlogs, d.h. einer Liste, in der die Komplexitäten der einzelnen Projektanforderungen ins Verhältnis zueinander gesetzt werden;
- Entwicklungsteam: Interdisziplinäres, selbstorganisiertes Team aus Fachkräften, das für die Planung und Durchführung einzelner Sprints verantwortlich ist;
- Scrum Master: Projektmanager, der als „Servant Leader“ für die Einhaltung wesentlicher Scrum‑Praktiken durch alle Projektbeteiligten verantwortlich ist.
Als Scrum‑Ereignisse sind die schon erwähnten Sprints, deren jeweilige Planung („Sprint Planning“), der „Daily Scrum“, d.h. ein tägliches Meeting des Entwicklungsteams während eines Sprints, das „Sprint Review“ (Überprüfung des im Sprint gefertigten Produktteils sowie ggf. Anpassung des Product Backlog) und die „Sprint Retrospektive“ zu nennen, bei der nach Abschluss eines Sprints kritisch das eigene Projektvorgehen hinterfragt und gegebenenfalls Anpassungen für zukünftige Sprints vereinbart werden sollen.
Neben dem Product Backlog existieren einzelne Sprint Backlogs, bestehend aus den jeweils für den Sprint ausgewählten Product Backlog-Einträgen. Als drittes sog. Scrum‑Artefakt existiert das Inkrement, womit das Ergebnis aus allen in einem Sprint fertiggestellten Product Backlog‑Einträgen und dem Resultat der Inkremente aller früheren Sprints beschrieben ist.
Rechtliche Einordnung des Projektvertrags muss im Einzelfall erfolgen
Im Konfliktfall streiten sich die Parteien regelmäßig um die rechtliche Einordnung des Projektvertrags. Dabei dreht sich der Streit im Kern um die Frage, ob der Vertrag als Dienst- oder Werkvertrag anzusehen ist. Der wesentliche Unterschied zwischen diesen beiden Vertragsarten besteht darin, dass bei einem Dienstvertrag der Auftraggeber die Ergebnisverantwortung trägt und bei einem Werkvertrag der Entwickler bzw. Auftragnehmer. Bei einem Dienstvertrag schuldet der Auftragnehmer nämlich lediglich ein Tätigwerden, also die Leistungserbringung als solche. Bei Werkverträgen ist hingegen ein Erfolg geschuldet und das fertige Produkt muss vom Auftraggeber abgenommen werden. Ist das erbrachte Werk mangelhaft, stehen dem Auftraggeber im Gegensatz zum Dienstvertragsrecht Gewährleistungsrechte wie Nacherfüllung, Schadensersatz, Minderung oder Rücktritt zur Verfügung.
Die Frage nach der rechtlichen Einordnung kann ohne vertragliche Festlegung häufig nicht eindeutig beantwortet werden. Über Jahre war es ständige Rechtsprechung des Bundesgerichtshofs, dass für die Herstellung von Individualsoftware Werkvertragsrecht gilt (vgl. BGH Urteil v. 7. März 1990 – VIII ZR 56/89). Jedoch basierte diese Rechtsprechung regelmäßig auf sequentiell angelegten Softwareprojekten (d.h. der Wasserfallmethode). Daher kann sie nicht ohne Weiteres auf agile Softwareentwicklung übertragen werden.
Eine höchstrichterliche Entscheidung ist insofern weder bereits ergangen noch ist diese zwingend zu erwarten. Denn ein pauschaler Befund würde dem sehr individuellen Charakter agiler Softwareprojekte nicht gerecht werden. In diese Richtung geht auch die bisher einzige obergerichtliche Entscheidung zum Thema agile Softwareentwicklung nach Scrum des OLG Frankfurt (Urteil v. 17. August 2017 – 5 U 152/16). Die Richter mussten den rechtlichen Charakter des Projektvertrags zwar nicht abschließend klären. Sie ließen jedoch erkennen, dass sie am ehesten von einem typengemischten Vertrag ausgehen, sowohl mit werk- als auch mit dienstvertraglichen Elementen.
Agile Softwareprojekte: Prävention statt Reaktion durch vertragliche Regelungen
Um langwierige Auseinandersetzungen zu vermeiden, sollte präventiv eine eindeutige vertragliche Regelung getroffen werden. Daran fehlt es in der Praxis häufig. Das liegt unter anderem daran, dass weder Auftraggeber noch Auftragnehmer eine umfassende Ergebnisverantwortung übernehmen wollen – der Auftraggeber möchte am Ende nicht ohne fertiges Produkt dastehen und der Auftragnehmer gerade bei agiler Entwicklung keine „Garantie“ für den Projekterfolg übernehmen.
Gleichwohl ist es für die Parteien ratsam, vor Projektbeginn einen möglichst detaillierten Vertrag aufzusetzen und Konfliktpotenzial zu antizipieren. Ansonsten ist Streit vorprogrammiert – weniger als die Hälfte aller IT‑Projekte werden in Deutschland erfolgreich abgeschlossen. Durch kreative vertragliche Gestaltungen können Kosten gespart und ein erfolgreicher Projektverlauf gefördert werden. Mehr Verantwortung hinsichtlich des Projekterfolgs kann beispielsweise durch höhere Vergütung oder weniger Haftung ausgeglichen werden. Nur so kann wirksam verhindert werden, dass die Parteien im Konfliktfall einen unbefriedigenden Vergleich schließen müssen oder sich gar vor Gericht wiederfinden.
Im zweiten Teil dieser Blogserie werden typische Probleme bei der Vertragsgestaltung beleuchtet und Gestaltungsalternativen aufgezeigt. Zudem wird der Frage nachgegangen, wie sich der Mitwirkungsbeitrag des Auftraggebers auf das Urheberrecht an der entwickelten Software auswirkt.
