Beitragsreihe: Verträge für agile Softwareprojekte – Unsere Empfehlung: Agile “Time and Materials”-Projekte

Die Beitragsreihe “Verträge für agile Softwareprojekte” setzt sich mit den schuld- und urheberrechtlichen Aspekten der agilen Softwareentwicklung auseinander. Unter der Prämisse, dass agile Verträge als Lösungsansatz auch für deutsche Unternehmen zunehmend Relevanz erlangen, diese Thematik bisher jedoch nur rudimentär aufgearbeitet wurde, wird anhand von Rechtsprechung und Literatur die gegenwärtige Rechtslage veranschaulicht. Schlussendlich werden Empfehlungen zu vertraglichen Regelungen ausgesprochen, die sich mit Blick auf die Vielzahl von Problemen und Risiken ergeben, die bei agilen Softwareentwicklungsprojekten zu erwarten sind.

Zurück zu Teil III: Konventionelle Vertragsmodelle

Agile Time and Materials-Projekte

Unsere Empfehlung für agile Projekte ist der Dienstvertrag mit definierten Prozessen und Sollbruchstellen. Die Risikoverschiebung des konventionellen Dienstvertrags zu Lasten des Auftraggebers wird durch dieses Konzept mit entsprechenden vertraglichen Regelungen aufgefangen. Diese Regelungen bieten bessere Kontroll- und Steuerungsmöglichkeiten, ermöglichen die frühzeitige Erkennung und effektive Lösung von Problemen, versprechen die vollständige Ausnutzung von Verbesserungs- und Einsparpotentialen und halten im Zweifel Sicherheitsmaßnahmen bereit, um durch Sollbruchstellen und ein geordnetes Exit Management eine einvernehmliche Trennung in beiderseitigem Interesse zu ermöglichen.

Die vertraglichen Regelungen sollten zuvorderst der klaren Definition der Arbeitsprozesse gelten. Die agile Softwareentwicklung am Beispiel des Scrum hat in der Praxis Arbeitsschritte entwickelt, die sich als produktiv erwiesen haben.[1] So empfiehlt es sich, Sprint Planning, Daily Scrum, Sprint Review, Sprint-Retrospective und Backlog Planning & Refinement als fortlaufendende Prozesse, bei denen sich Product Owner und Dienstleister oder das Entwicklerteam untereinander über die konkrete Gestaltung des Produkts austauschen und eine Bewertung der eigenen Leistungen und des derzeitigen Standes des Produkts vornehmen, als vertragliche Verpflichtung vorzusehen.

Im Vertrag sollte auch die Rolle des Product Owners als Vertreter des Auftraggebers geregelt werden.[2] Dem Product Owner sollten im Vertrag Entscheidungsbefugnisse übertragen werden, aus der sich seine Verantwortung für das Projekt ableiten lässt. Seine Verfügbarkeit sollte ebenso vertraglichen Regelungen unterliegen wie der Einsatz eines Proxy Product Owners[3] und Rechtsfolgen von Verzögerungen auf Seiten des Product Owners.

Die personelle Konsistenz des Entwicklerteams ist ein weiteres wichtiges Anliegen. Jegliche persönliche Änderung geht mit einem Verlust von spezifischem Wissen oder der notwendigen Einarbeitung eines neuen Mitglieds einher. Da sich dies stets negativ auf die Projektkosten und -dauer auswirkt, sollte ein definierter Anteil des Teams gleich bleiben müssen. Gleichwohl sollte ein Verfahren vorgesehen werden, um besonders wichtige Teammitglieder bei ihrem Ausscheiden aus dem Team mit vergleichbar qualifizierten Mitarbeitern zu ersetzen. Dies erlaubt es dem Auftraggeber, trotz der Beauftragung eines externen Dienstleisters, weitgehend die Kontrolle über die Zusammensetzung des Entwicklerteams zu behalten und die Erfolgswahrscheinlichkeit des Projekts zu erhöhen.

Exit Management

Durch ein Exit Management im Vertrag soll der Auftraggeber in die Lage versetzt werden, bei vorzeitigem Abbruch des Projekts mit dem bisherigen Dienstleister, also im worst case scenario, ohne Übergabe-Problematik möglichst nahtlos einen neuen Dienstleister beauftragen zu können. Dies erfordert Sollbruchstellen im Projekt, die bei übermäßiger Belastung der Geschäftsbeziehung oder einem sich abzeichnenden Misserfolg ein einvernehmliches Loslösen vom Vertrag erlauben. In diesem Zusammenhang sollten auch die Kündigungsfristen so bestimmt werden, dass beide Parteien genug Zeit für Abschlussvorbereitungen erhalten, um beispielsweise die Dokumentation vervollständigt übergeben zu können. Besonders bei Festpreismodellen ist eine Übergaberegelung hinsichtlich der bereits geleisteten Arbeitsleistung vorzusehen. So kann sich die zu leistende Zahlung anteilsmäßig auf den Prozentsatz der vervollständigten Arbeit oder auf die anteilige Auftragsdauer beziehen.

Abschließend sollte im Vertrag zu Art und Umfang der Dokumentation ausgeführt werden, welche Projektarchitektur vorgesehen ist, ob die Dokumentation im Code vorhanden sein soll oder Clean Code mit eigenem Handbuch bevorzugt wird. Die „Definition of Done“ als Kriterienkatalog[4], um ein Feature als fertig implementiert erachten zu dürfen, sollte ebenso nicht dem beliebigen Empfinden der Vertragsparteien unterliegen, sondern möglichst eindeutig im Vertrag zu finden sein.

Weiter zu Teil V: Die Rechtsprechung

[i] Schwaber/ Sutherland, The Scrum Guide, S. 9 ff.
[ii] Schwaber / Sutherland, The Scrum Guide, S. 5.
[iii] s. hierzu: Pichler, Agile Product Management with Scrum, S. 41.
[iv] ScrumAlliance, Scrum, S. 9.

RA Bilal Abedin
Wiss. Mit. Burak Zurel