So kann z. B. gemeinsam mit Dienstleistern an Smart-Tool-Lösungen für das bestehende Produktportfolio gearbeitet werden, wozu je nach noch zu eruierendem Nutzerverhalten der Kunden digitale Zusatzfunktionen entwickelt werden sollen. Dazu kommen regelmäßig Software-Tools, wie z. B. Kanban oder SCRUM, zum Einsatz, um Teilziele zu dem gemeinsamen Projekt zu definieren. Diese können flexibel auf sich verändernde Rahmenbedingungen angepasst werden und gewähren einer innovativen Herangehensweise möglichst viel Raum. Zeigt z. B. das Nutzerverhalten der Kunden, dass eine Interaktion zwischen den angebotenen Produkten als besonders wichtig erachtet wird, wird der Lösungsansatz ein völlig anderer sein, als wenn den Kunden ausschließlich am Remote-Zugriff auf einzelne Produkte gelegen ist. Entscheidend für den beidseitig erfolgreichen Abschluss agiler Projekte ist ein gemeinsames Verständnis der Vertragspartner u. a. darüber, welche Leistungen wie erbracht werden, wann diese als erfüllt gelten und abgenommen werden können, sowie wie die Vergütung ausgestaltet wird. Dies muss auch seinen Niederschlag in der Vertragsgestaltung finden.
Standardverträge sind nicht geeignet
Standardklauseln, die dem Werk- und/oder dem Dienstrecht entstammen, eignen sich regelmäßig nicht, zur Gestaltung von agilen Verträgen. Denn es gilt der agilen Methodik und dem agilem Mindset Rechnung zu tragen. Dazu ist letztlich ein Loslösen von den bekannten Vertragstypologien erforderlich. Entscheidend muss sein, wie die agile Zusammenarbeit konkret ausgestaltet ist, und diese in rechtsverbindliche Regelungen umzusetzen.
Ausgestaltung am Beispiel von SCRUM
Die erste Zutat für einen umsetzbaren und damit guten agilen Vertrag ist die Beschreibung und Regelung der tatsächlichen Ausgestaltung der agilen Zusammenarbeit. Hierzu ist es unerlässlich, sich mit den Grundzügen der Methodik des eingesetzten Software-Tools und dem agilen Mindset auseinanderzusetzen. Von besonderer Bedeutung für die Zusammenarbeit sind die Rollen, die das eingesetzte Software-Tool vorsieht. Bei SCRUM sind dies konkret der Product Owner, das Entwicklungsteam und der SCRUM-Master. So wird der Product Owner zwar oftmals mit dem Auftraggeber identisch sein bzw. von diesem gestellt werden. Als Product Owner kann aber auch eine andere Person definiert werden, die letztlich die Interessen des Auftraggebers vertritt und aufgrund seiner guten Marktkenntnisse am besten die zu realisierenden Produkteigenschaften und Produktfunktionalitäten bestimmen kann. Das Entwicklungsteam wird jeweils nach den Zielen individuell und ggf. multidisziplinär zusammengestellt. Unterstützt wird die Arbeit des Entwicklungsteams durch den SCRUM-Master, der als Moderator und Vermittler unterstützt.
Ein klares gemeinsames Rollenverständnis der Vertragsparteien ist für die Vertragsgestaltung essentiell. Oftmals wird es Aufgabe des bei der Vertragsgestaltung hinzugezogenen Beraters sein, hier dieses Verständnis zu schärfen.
Definition von Abnahmen
Mit eine der größten Herausforderungen bei der agilen Vertragsgestaltung ist regelmäßig die Regelung der Abnahme. Bei der Gestaltung einer agilen Abnahmeklausel gilt es zunächst, den Gegenstand der Abnahme zu identifizieren und zu beschreiben. Weit verbreitet ist der Irrglaube, dass sich bei agilen Projekten nicht definieren lässt, wie das Ergebnis aussehen soll. Trotz der Möglichkeit, die Ergebnisse immer wieder anzupassen, bestehen zumeist diverse Grundannahmen beim Auftraggeber im Hinblick auf das Ergebnis, die in einem Product Backlog festgehalten werden. Wichtig ist, dass der Inhalt dieses Product Backlogs nicht zum Gegenstand der Abnahme gemacht wird, weil damit das Product Backlog dem klassischen Pflichtenheft gleichsetzt, was jedoch nicht zum Ansatz des agilen Arbeitens entspricht. Im Eingangsbeispiel wäre etwa die Entwicklung digitaler Zusatzfunktionen zu den bestehenden Produkten im Produkt Backlog festzuhalten.
Der Inhalt des Sprint Backlogs, mit dem die Aufgaben innerhalb einer vorgegebenen Zeitspanne zur Erzielung eines Zwischenergebnisses definiert werden, kann hingegen Gegenstand der Abnahme sein. Das zu Beginn des agilen Projekts grob definierte Werk wird damit im Wege der agilen Entwicklung mit jedem Inkrement, dem Ergebnis aus einem erledigten Sprint, immer weiter konkretisiert. Die Sprintreviews können hierbei als Teilabnahme genutzt werden, wenn diese ähnlich einem Abnahmeprotokoll schriftlich dokumentiert sind. Wurde im Beispielsfall definiert, dass die Interaktion der Produkte im Vordergrund steht, und dazu in einem Sprint Backlog vereinbart, dass mittels einer zu erstellenden digitalen Schnittstelle ein Produkt sich autonom betriebsbereit schalten soll, sobald sich ein anderes Produkt innerhalb eines Radius von 20 m befindet, könnte dies Gegenstand einer Abnahme sein.
Für die Gesamtabnahme gibt es zwei unterschiedliche Herangehensweisen: Entweder muss zur Erzielung der Abnahmefähigkeit eines Werks eine sog. Frozen Zone des Product Backlogs eingerichtet werden, innerhalb derer das Product Backlog nicht mehr geändert werden darf. Zwar kann dieses Vorgehen den agilen Prozess verlangsamen, bringt aber einen sinnvollen Abschluss für das Projekt. Oder aber das sog. Automated Testing kommt zum Einsatz. Dies ersetzt eine Abnahme zu jedem von den Parteien gewünschten Zeitpunkt. So kann das als Inkrement oder sog. Shippable Product erzielte Teilergebnis, das nach jedem Sprint grundsätzlich vorhanden sein sollte, sogleich in der Praxis eingesetzt werden, da immer eine Abnahme erfolgt. Vorteile bringt dieses Vorgehen insbesondere bei Projekten mit einer kurzen Time-to-Market-Zeitspanne oder bei denen eine frühzeitige Kundenreaktion maßgeblich für die weitere Entwicklung ist. Allerdings sind hohe Anforderungen an die Technik und die Betriebsumgebung, inklusive entsprechender Verantwortlichkeiten sowie die herausfordernde Kalibrierung für das Testing zu meistern. Sofern das Automated Testing genutzt wird, ist in den Abnahmeregelungen festzuhalten, wie und durch wen die Ergebnisse des Testing abgerufen und dokumentiert werden und welche Rechtswirkung dies haben soll. Im Beispielsfall könnte vereinbart werden, dass 14 Tage nach einem Software-Update der Produkte mit der Zusatzfunktion der autonomen Inbetriebnahme ermittelt wird, wie oft Kunden autonom eingeschaltete Produkte sofort wieder abschalten und sich damit diese Zusatzfunktion als nicht erwünscht erweist.
Kernpunkt der Vertragsgestaltung: die Vergütung
Im Rahmen von agilen Verträgen wird letztlich zwischen drei Vergütungsmodellen unterschieden:
Beim agilen Festpreis werden sog. User Stories, also Beschreibungen der Anwendung eines Produkts, dem Aufwand nach geschätzt und es werden sog. Story Points, mit der die Größe der User Story beschrieben werden, vergeben. Daraus ergibt sich ein Pauschalpreis, der durch die Anpassung der User Stories und damit der Story Points modifiziert werden kann. Erschwert wird dadurch allerdings die Beendigung des Projekts. Eine Abwandlung dessen sieht vor, dass auch im Rahmen von Vereinbarungen zum agilen Festpreis das Projekt nach jedem Sprint beendet werden kann und dann nur die bis dahin vom Auftraggeber genutzte oder nutzungsfähige Software bzw. das erzielte Produkt zu bezahlen ist. Klärungsbedürftig ist hier allerdings, wie das Vergütungsrisiko auf die Parteien interessengerecht verteilt wird.
Beim Pay-per-Sprint-Modell wird nach jedem oder für jeden Sprint gezahlt. Dies kann allerdings bei Vereinbarung einer konkludenten Abnahme zu Komplikationen führen. Zudem wird die Bedeutung von Sprintreviews gesteigert, die ggf. unbeabsichtigt gegen Ende des Projekts komplexer und länger werden können, sodass die Effizienzgewinne der agilen Methode gefährdet sind.
Schließlich gibt es Bonus-/Malus-Modelle, die auf eine gewisse Erfolgsbelohnung abzielen und z. B. 20 % mehr Vergütung versprechen, wenn das Produkt nach acht anstelle von zehn Sprints fertiggestellt wird. Dieses Modell birgt die Gefahr, dass die Qualität des Produktes leidet, weil es vorrangig um ein vorgegebenes zeitliches Ziel geht.
Weiterer Regelungsbedarf
Alle weiteren für einen agilen Vertrag typischen Klauseln sind mit Blick auf dessen Besonderheiten zu gestalten. Grundsätzlich gilt, dass stets anhand der Parteiinteressen abgewogen werden muss, welche Standards in welchem Umfang benötigt werden und wie sich diese auf die Agilität des Projektes auswirken können. So bedarf es keiner umfangreichen Garantie eines MVP (Minimal Viable Product), also einer Entwicklungsstufe des Produkts, in der es erstmals real getestet werden kann, wenn sich bereits abzeichnet, dass diese sich in naher Zukunft noch verändern könnte. Zudem sind Nutzungsrechte und die Art und Weise der Dokumentation in Form von Handbüchern und Entwicklungsdokumentationen zu regeln.
Fazit
Bei agilen Verträgen sind die Vertragsparteien und deren Berater gefordert, wie auch beim agilen Arbeiten an sich, gewohnte Pfade zu verlassen. Vielmehr sind individuelle Regelungen notwendig, die den agilen Werten gerecht werden. Standardlösungen verbieten sich damit zumeist. Sofern sich aber die Vertragsparteien über das Ziel und die Rahmenbedingungen einig sind, können durchaus pragmatische Lösungen gefunden werden. Beratern mit einem vertieften Verständnis zum agilen Arbeiten kommt dabei eine zentrale Rolle zu.
