Agile Softwareentwicklung und „Scrum“: Vertragsrechtliche Besonderheiten

Von RA und Fachanwalt IT-Recht Dr. Jens Bücking, Stuttgart

Einführung

 

Die stark im Vordringen begriffene agile Softwareentwicklung – und hier insbesondere das Vorgehensmodell des „Scrum“ – verfolgt einen von der klassischen „Wasserfallmethodik“ abweichenden Ansatz, bei dem – vereinfacht gesagt – die entscheidende Vertragsgrundlage der ständigen Anpassungen unterworfene „agile Projektplan“ mit seinen steten Anpassungen unterworfenen jeweiligen Zeiten, Aktionen, Funktionen, Budgets und Beteiligten ist  (vgl. Decker, Blog IT-Recht, http://blog-it-recht.de/2014/02/21/vertragsgestaltung-bei-agiler-softwareerstellung-teil/ ) – letztlich, so würden Skeptiker mit Neigung zu Sarkasmus anmerken, ein Credo, also ein bloßes Glaubens-Bekenntnis ohne hinreichende Rechtssicherheit?

 

Nachdem sich in der Praxis allerdings erwiesen hat, dass insbesondere Großprojekte im Bereich der Softwareeinführung und Anpassung oftmals zu komplex sind, um vorab mit durchgeplant werden zu können, soll diese in der gelebten Wirklichkeit häufig zu Krisen, Projektabbrüchen und langwierigen (auch: juristischen) Prozessen führende Komplexität durch vornehmlich drei Prinzipien durchbrochen werden:

 

  1. Transparenz: Der Projektfortschritt und seine Risiken und Hemmnisse werden in kurzen Zeitabständen für alle Beteiligten dokumentiert.

 

  1. Überprüfung / Kontrolle: In ebenfalls kurzen, regelmäßigen Zeitabständen werden Funktionalitäten implementiert, getestet, beurteilt und wiederum dokumentiert.

 

  1. Anpassung: Die Anforderungskriterien sind nicht starr sondern ständiger Neubewertung und Anpassung unterworfen.

 

(Instruktiv zum Ganzen nochmals Decker, Blog IT-Recht, a.a.O.)

 

Dem gemäß wird bei dieser Form der Softwareentwicklung auf Leistungsbeschreibungen in Gestalt von Lasten- und Pflichtenheften weitestgehend verzichtet. Eine eigentliche Planungsphase im engeren Sinne wird obsolet. Verzichtet wird insbesondere auch auf die sogenannten Change Requests, da der Prozess der agilen Entwicklung eben gerade durch die fortlaufende Veränderung charakterisiert wird.

 

Auch die Beteiligten und Verantwortlichkeiten verschieben sich, dies wiederum in Abkehr von dem klassischen Projektmanager mit seinen Lenkungsausschüssen, Projektteams, Key User-Gruppen etc. Die neuen Protagonisten heißen Product Owner, ScrumMaster, Entwicklungsteam, Management, Customer und User und sollen kurzfristige, realistische, nutzbare und hierbei oft sämtliche verfügbaren Energien bündelnde Etappenziele erreichen, dies mittels sog. „Sprints“.

Kooperation und Information in den Entwicklungsteams vollziehen sich in „Sprint Planning Meetings“, „Daily Scrum“, „Sprint Review“ und „Retrospektive“.

„Product Backlog“ wird die unter Prioritätsgesichtspunkten erstellte Liste genannt, die definiert, was die Software leisten können sollte (einschließlich etwaiger Änderungsanforderungen). Der „Product Owner“ verantwortet die Eintragungen ins Product Backlog und deren Priorisierung.

Charakteristisch für den agilen Ansatz nach „Scrum“ ist, dass das Product Backlog weder abschließend sein kann noch soll. Zu Beginn eines Projektes enthält es einen Katalog von bekannten und am besten verstandenen Anforderungen. Die Priorisierung der Eintragungen erfolgt sodann unter von den Beteiligten festgelegten Kriterien wie beispielsweise wirtschaftlicher Nutzen, Risiko und Notwendigkeit. Eintragungen mit der höchsten Priorität werden als erste im Sprint umgesetzt. Allerdings ist all dies den jeweils zu Tage tretenden Änderungsbedürfnissen und -Wünschen unterworfen. Das Product Backlog verändert sich also iterativ zusammen mit dem Produkt und der Arbeitsumgebung (vgl. Sutherland / Schwaber, The Scrum Guide, S. 12).

Das „Sprint Backlog“ gibt eine Übersicht über die in einem bestimmten Sprint zu erledigenden Aufgaben. Hierfür wird oft ein aus 4 Spalten bestehendes „Taskboard“ genutzt („User Stories“ des Entwicklungsteams, „Tasks“ aus den einzelnen User Stories [„to do“; „in progress“; „done“).

 

Der ScrumMaster führt ein „Impediment Backlog“, in dem alle Fehler, Störungen und sonstigen Hindernisse eingetragen, beschrieben und bis zu ihrer Obsolenz dokumentiert werden (vgl. Pichler, Scrum: Agiles Projektmanagement erfolgreich einsetzen, S. 119).

 

Dies vorausgeschickt, ergeben sich für die Beratungs- und Kautelarpraxis eine Reihe von Besonderheiten, die sich insbesondere in der Abkehr vom erfolgsbezogenen Werkvertragsmodell erweisen.

 

(Vor-) Planungsphase

 

Die eigentliche Planungsphase im herkömmlichen Sinne entfällt. Aufgrund des gewünschten Verzichts auf einen im Detail durchgeplanten Anforderungskatalog könnte erwogen werden, die in die Vorphase der Auftraggeberverantwortung fallende Planung zu trennen von der Realisierung des Softwareprojekts und die projektbezogene Zusammenarbeit sodann dienstvertraglich auszugestalten, was allerdings häufig auf Widerstand beim Auftraggeber führen wird.

 

Eine angemessene Berücksichtigung seiner Interessen und Bedürfnisse ließe sich ggfls. durch die Definition von Teilprojekten auf Werkvertragsbasis bewerkstelligen.

 

Projektphase

 

Im eigentlichen Projektverlauf sollten sich die Vertragsparteien auf unternehmenskritische, unabdingbare Funktionalitäten und deren Zeithorizont verständigen – und diese ggfls. trennen von allen anderen, nützlichen und wünschenswerten Funktionalitäten. Dies ermöglicht bei entsprechender vertraglicher Ausgestaltung auch eine Abtrennung von dann abnahmefähigen Teilleistungen (vgl. Frank, CR 2010, S. 138).

 

Einzelne „Sprints“ können als isolierte Werkverträge ausgestaltet sein. Nötig wären dann die Definition eines Teilerfolgs im Rahmen des Sprint Planning Meeting und die Festschreibung dieses Teilerfolgs im Sprint Backlog, um hier auf der Ebene der Projekteinführung die Auftraggeberbelange entsprechend berücksichtigen zu können. Zu vermeiden ist hierbei allerdings unbedingt, 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.

 

Hiergegen wird eingewandt, dass es – nun wieder aus Sicht des Auftraggeberinteresses – hier an einem definierbaren Erfolgsmoment fehlt und als Kompromiss vorgeschlagen, die Entwicklung einer ersten Fassung einer lauffähigen und demonstrierbaren Grundfunktionalität dem Werkvertragsrecht oder Werklieferungsrecht zuzuordnen, die hieran anknüpfenden Weiterentwicklungen und Anpassungen sodann allerdings dem Dienstvertragsrecht (vgl. Koch, ITRB 2010, S. 114). Erforderlich wäre hier dann allerdings ein wiederum einen Teil der Agilität absorbierender Katalog von Grundfunktionalitäten und deren Definition.

 

Projektbeteiligte und Projektverlauf

 

Bei den Beteiligten ist zu regeln, wer das Projekt, dessen Verlauf und Ergebnis verantwortet und wer lediglich bis zu welchem Grade Mitwirkung schuldet.

 

Änderungen im Zeit- und Aktionenplan, aber auch bei Funktionsumfang und Budget sind bei agilen Softwareprojekten der gewünschte dynamische Rahmen, der den Vertragsparteien ihre Handlungsweisen und Planungen vorgibt. Das Projekt soll so veränderlich bleiben, wie es die Anforderungen des Auftraggebers sind.

 

Um den Nutzen der agilen Entwicklung zu realisieren, bedarf es eines ständigen Informationsaustauschs zwischen den Projektbeteiligten über Arbeitsziele, deren Umsetzung, Änderungen, Erweiterungen, Reduzierungen, Qualität von Leistungen, Zeitfaktoren, personelle Ressourcen, Budgets etc.

 

Vertragsgestaltung

 

In vertraglicher Hinsicht ist hier für eine Feinjustierung im laufenden Projekt, die sich letztlich ebenfalls fortlaufend an den sich rasch anpassenden Projektläufen zu orientieren hätte, kein Platz. Den Parteien kann daher nur ein Rahmen gesetzt werden, und der eingangs erwähnte agile Plan kann als fortlaufendes „Credo“ des Projekts fungieren.

 

Die Festschreibung bestimmter Meilensteine, Teilergebnisse oder gar der Software insgesamt wäre mit Zielen und Nutzen agiler Entwicklung unvereinbar. Wichtiger ist vielmehr, dass die Vertragsparteien sich auf ihre jeweiligen Qualifikationen verständigen sowie Grundsätzliches über die jeweilige Verantwortungssphäre, da in agilen Softwareprojekten aus der Mitwirkung eine Leitungs- und Lenkungsaufgabe – und mithin in der Regel eine Hauptpflicht (auch und gerade) des Auftraggebers – wird. Den jeweiligen Qualifikationen der Vertragsparteien im Produkt- und Personalbereich kommt daher essentielle Bedeutung zu. Gleiches gilt für die Arbeitsabläufe, die einzusetzenden Tools, den Support nach Art, Umfang und Zeiten und Vergütungsbestandteile (vgl. Hengstler, ITRB 2012, S. 113).

 

Für die vertragsrechtliche Einordnung ist wichtig sich vor Augen zu 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. Zu demselben Ergebnis können vertragliche Festlegungen zu den jeweiligen Arbeitsinhalten und deren Umfang sowie der vom Erfolg dieser Arbeiten abhängigen Vergütung führen. In der Vertragspraxis kommt daher – je nach gewünschtem Blickwinkel – diesen Aspekten erhebliche Bedeutung zu, insbesondere was die Überlassung eines in irgendeiner Weise für den Auftraggeber konzipierten und im Rahmenkontext verwertbaren Ergebnisses anbelangt.

 

Hier erhält die Rolle des Product Owner besondere Bedeutung, da dieser die Produktanforderungen – gerade auch vor dem Hintergrund der vorhandenen Budgets – definiert und ihm die Verantwortung für Inhalt und Einsatz des zu entwickelnden Systems zufällt. Um beurteilen zu können, ob die Leistungserbringung den planerischen Grundvorgaben entsprechend zielführend ist, muss der Product Owner von den Vertragsparteien nach strengsten qualifikatorischen Gesichtspunkten, die keinesfalls gegenüber den jeweiligen Teammitgliedern abfallen sollte, ausgewählt und mit den zugehörigen Kompetenzen versehen werden. Hiermit einher gehen naturgemäß Weisungsbefugnisse, um genau solche Änderungen in der Priorisierung, Zieldefinition und Budgetierung anstoßen und umsetzen zu können (vgl. Hengstler, a.a.O.). Dieser Verantwortungsbereich fällt grundsätzlich dem Auftraggeber zu.

 

Die Entscheidung für eine ausschließlich oder zumindest überwiegend dienstvertragliche Ausgestaltung hat denknotwenig das Entfallen der klassischen Gewährleistungsrechte zur Folge; hier kann aus Sicht des Auftraggebers Kompensation durch kurzfristige Kündigungsrechte geschaffen werden.

 

Weder bei Auftragserteilung noch im Entwicklungsprozess existieren verbindlichen Vorgabe, da sich diese erst während des Projektes formieren. Insofern besteht denknotwendig bis zuletzt eine Unschärfe etwa über die jeweils aktuellen Verantwortlichkeiten oder die jeweils zu erbringende Leistung und deren Abnahmekriterien, derer sich die Vertragsparteien gewärtig sein müssen. Auch unter dem Aspekt der Produkthaftung gilt es für jedes Projekt im Einzelfall die Sinnhaftigkeit der agilen Vorgehensweise zu prüfen. Wird all dies mit der gebotenen Sorgfalt geprüft und gestaltet, kann die agile Softwareentwicklung eine der klassischen Methodik an Geschwindigkeit, Kosten, Effizienz und Mehrwert deutlich überlegene Option darstellen.