Nach einer kurzen Einführung in die Thematik der agilen Methodik anhand von Scrum (I.) und einer zusammenfassenden Darstellung des rechtlichen Spannungsfeldes (II.) unterbreitet der Beitrag konkrete Klauselvorschläge (III.) um mit einer Checkliste (IV.) zu schließen.

Inhaltsverzeichnis

I. Einführung
1. Was ist agil am Beispiel von Scrum
2. Agile Tools

II. Vorfragen der Vertragsgestaltung
1. Vorvertragliche Aufklärungspflichten
2. Vorprojekt
3. Dienstvertrag vs. Werkvertrag
a) Bisher vertretene Auffassungen
b) Entscheidung des OLG Frankfurt a.M.
c) Stellungnahme und alternativer Ansatz
4. Arbeitsrechtliche Besonderheiten

III. Vertragliche Ausgestaltung
1. Präambel
2. Beschreibung des Werkes und fortschreitende Konkretisierung
3. Zusammenarbeit / Scrum-Ausgestaltung
a) Agile Grundsätze
b) Product Owner
c) Business Owner
d) Entwicklungsteam
e) Scrum Master
f) Agile Tools
g) Backlogs und dessen Pflege
h) Teilnahme des Scrum-Teams (des AN) an Meetings als Hauptpflicht
4. Eskalationsverfahren
5. Change-Request-Verfahren
6. Abnahmeregelungen inkl. Frozen-Zone
a) Teilabnahmen
b) Gesamtabnahme
7. Gewährleistung
a) Vor Gesamtabnahme
b) Nach Gesamtabnahme
8. Rechteeinräumung
a) Zeit und Umfang
b) Zugriff auf den Quellcode
c) Sonstige Leistungen (Konzepte, usw.)
d) Open Source Komponenten
e) Sonderproblem: gemischte Teams
9. Vergütung
a) Time & Material (T&M)
b) T&M mit Umsatzrückvergütung
c) 70 % T&M – 30 % Bonus bei Zielerreichung
d) Agiler Festpreis
e) Pay-per-Sprint

IV. Fazit und Checkliste

---

I. Einführung

Die Frage der kautelarjuristischen Behandlung von agilen Projekten wird bereits seit mehreren Jahren in Literatur und Praxis kontrovers diskutiert. Vor dem Hintergrund der jüngst zu einem agilen Projekt nach der Scrum-Methode ergangenen Rechtsprechung hat diese Diskussion erneuten Aufwind erlebt. Mitunter werden auch konkrete Gestaltungshinweise erteilt, ohne dass konkrete Formulierungsvorschläge unterbreitet werden. Nicht ohne gänzlich auf eine kurze Einführung in die agile Methodik und den Stand der rechtlichen Diskussion zu verzichten, bietet der Beitrag für eine ausgewählte Fallgruppe konkrete Vorschläge für Klauseln für einen agilen Werkvertrag.

1. Was ist agil am Beispiel von Scrum

Scrum ist wahrscheinlich aktuell das populärste agile Vorgehensmodell. Mit 85 % ist einer aktuellen Studie zu Folge Scrum die meistgenutzte agile Methode. Scrum bietet eine auf konkrete, Rollen gestützte Anleitung zur praktischen Durchführung agiler Softwareentwicklung, ohne durch ein komplexes Regelwerk die Akzeptanz aller Beteiligten zu gefährden. Denn der Erfolg agiler Projekte bzw. Produktvorhaben hängt in einem hohen Maße davon ab, dass auch ein „agiles Mindset“ gelebt wird.

Diesem Ansatz muss auch die Vertragsgestaltung gerecht werden. Es wäre verfehlt, Scrum nunmehr mit denselben Werkzeugen in kautelarrechtlicher Hinsicht anzugehen, wie sie bei einem Wasserfallprojekt zum Einsatz kommen. Auch Versuche, Scrum-Projekte mit Analogien baurechtlicher Vorgehensweisen „in den Griff“ zu bekommen, erscheinen nicht zielführend. Die Vertragsgestaltung agiler Werkverträge für Scrum muss die Rollen und Prozesse von Scrum samt deren Charakteristika berücksichtigen. Der Scrum-Guide ist eine leicht verständliche und schnell einführbare Anleitung für ein agiles Vorgehensmodell auf Basis von Scrum, die Ausgangspunkt weitergehender Vertragsgestaltung sein kann, allerdings nicht einfach nur als Anlage zum Vertrag genommen werden sollte. Der iterative Ansatz verfolgt das Ziel nach jedem Sprint ein lauffähiges Softwareprodukt, welches potentiell auslieferbar wäre, zu erreichen6. Innerhalb eines Sprints soll das Entwicklungsteam ein fertiges, nutzbares und potentiell auslieferbares Produktinkrement für den Auftraggeber herstellen. Um dem Gedanken der Agilität in angemessenem Umfang gerecht zu werden, muss im Rahmen dieser agilen Vorgehensweise Fortschritt und Abweichungen regelmäßig überprüft und ggf. angepasst werden. Hierzu sieht Scrum vier formale Ereignisse vor: Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive. Diesen Ereignissen kommt aus Sicht eines agilen Werkvertrages erhebliche praktische Bedeutung zu, da sich hier sowohl die Herstellung oder Veränderung des Produkts als auch ein damit zusammenhängender herbeizuführender Erfolg (Sprint-Ziel) definieren und abnehmen lassen.

Für die vorliegende Betrachtung sind vor allem die nachfolgenden Grundaussagen nach Scrum von Bedeutung:

• Entwicklungsteams sind selbstorganisierend, niemand sagt ihnen, wie es aus dem Product Backlog potentiell auslieferbare Funktionalität erzeugen soll. Ausschließlich das Entwicklungsteam bestimmt die Anzahl der ausgewählten Product Backlog Items für den kommenden Sprint, da nur sie beurteilen können, welcher Aufwand damit verbunden ist („Pull-Prinzip“).
• Im Sprint Review muss ein fertiges Inkrement vorhanden sein.
• Der Product Owner ist die einzige Person, die für das Management des Product Backlog verantwortlich ist. Er kann sich hierbei vom Auftragnehmer (z.B. Entwicklungsteam) unterstützen lassen, der Grundgedanke von Scrum schreibt aber eine ausschließliche Verantwortlichkeit des Product Owner für das Management, insbesondere die Priorisierung des Backlog vor.
• In laufende Sprints darf nicht eingegriffen werden, ausschließlich der Product Owner kann einen Sprint vorzeitig abbrechen. Änderungswünsche können frühestens im nächsten Sprint berücksichtigt werden.

2. Agile Tools

Das Scrum-Framework basiert auf Transparenz und einer intensiven Kollaboration der verschiedenen Rollen, weswegen sich der Einsatz agiler Produktmanagementsoftware (im Folgenden: Agile Tools) in der Praxis bewährt hat, die diese Werte unterstützen. Hierüber kann der Auftraggeber idealerweise jederzeit nachvollziehen, welcher Mehrwert gerade geschaffen wird und er kann ungewollten Entwicklungen über den Product Owner oder neue User Stories gegensteuern.

Verbreitet sind dabei insbesondere Webanwendungen, die Fehlerverwaltung, Problembehandlung und Projektmanagement ermöglichen und wie z.B. Jira auch eine Zuordnung zu einem Ticket ermöglichen. Zusätzlich kommt meist ein Kommunikations- bzw. Wissenssystem wie z.B. Confluence zum Einsatz, welches die Organisation und den Informationsfluss unter den Beteiligten fördert. Üblich ist weiterhin die Nutzung von toolgestützter Sourcecodeverwaltung/bzw. Quellcode-Repositories auf denen eine kollaborative Versionsverwaltung möglich ist. Derartige Systeme erlauben es dem Auftraggeber, alle in die Quellcodeverwaltung eingecheckten Änderungen einem Ticket zuzuweisen, so dass die Nachvollziehbarkeit sämtlicher Änderungen gewährleistet wird.

Die von Scrum vorgesehene Transparenz, die mit derartigen Ticket- und Wissensmanagementsystemen bzw. Repositorien erreicht werden kann, bietet für Auftraggeber erhebliche Vorteile im Hinblick einer Risikoreduzierung. Durch eine laufende Kontrolle des Fortschritts, der Qualität, der Entwicklungsleistungen und des Zeit-/Kostenaufwandes bekommt der Auftraggeber idealerweise ein aktuelles Bild von der Leistung des Auftragnehmers und kann somit rechtzeitig reagieren, wenn er nicht die erhoffte Qualität oder den erhofften Produktfortschritt erhält. Von besonderem Vorteil aus Sicht des Auftraggebers ist es außerdem, wenn die Entwicklungs- und Dokumentationsleistungen des Auftragnehmers laufend direkt auf Systemen des Auftraggebers eingecheckt werden, da er – sollte der Vertrag vorzeitig beendet werden – so kurzfristig einen Anbieterwechsel realisieren könnte.

II. Vorfragen der Vertragsgestaltung

Ausgehend von den obigen Grundsätzen und Besonderheiten sind im Rahmen der Vertragsgestaltung (dazu III.) weichenstellende Vorfragen zu beachten und zu berücksichtigen.

1. Vorvertragliche Aufklärungspflichten

Bereits in der Phase von Vertragsverhandlungen trifft grundsätzlich sowohl den Auftraggeber als auch den Auftragnehmer die Pflicht, die andere Partei über Umstände aufzuklären, die für diese hinsichtlich des Vertragsschlusses von gehobener Bedeutung sind (vgl. §§ 311 Abs. 2, 241 Abs. 2 BGB ).

Hier geht's direkt zum Aufsatz in juris PartnerModul IT-Recht:
Login für registrierte Kunden

Weiterlesen im CR Schnupperabo:
hier