Warum klassische Verträge bei Agilität klemmen
Der klassische Projektvertrag setzt voraus, dass zu Beginn bekannt ist, was geliefert werden soll: Pflichtenheft, Festpreis, Abnahme des Gesamtwerks. Agile Vorgehen wie Scrum gehen dagegen davon aus, dass Anforderungen erst im Lauf des Projekts entstehen und laufend priorisiert werden. Der Agile Leitfaden der Bundeskanzlei bringt den Unterschied auf den Punkt: Bei agilem Vorgehen liegt der Fokus auf Laufzeit und Ressourcen, Änderungen wirken primär auf Umfang und Leistung; klassisch ist es umgekehrt.[3]
Ein Vertrag, der beides gleichzeitig verlangt — fixen Umfang, fixen Preis und laufende Änderungen —, erzeugt Konflikte. Die Schweizer Fachliteratur spricht von der «Quadratur des Kreises» und beschreibt Modelle, die Fixpreise mit Elementen eines Aufwandpreises mit Kostendach verbinden.[1]
Welche Vertragsmodelle gibt es?
Welches Modell passt, hängt vor allem davon ab, wie viel Unsicherheit über den Umfang besteht und wie eng Kunde und Anbieter zusammenarbeiten können. Je grösser die Unsicherheit, desto eher passen aufwandsbasierte Modelle mit Kostendach.
| Modell | Funktionsweise | Risiko für Kunde | Risiko für Anbieter |
|---|---|---|---|
| Aufwand (Time and Material) | Vergütung nach geleisteten Stunden | Budget offen | Gering |
| Aufwand mit Kostendach | Vergütung nach Aufwand bis zu einer Obergrenze | Begrenzt | Mehraufwand über dem Dach |
| Festpreis pro Sprint | Fixer Betrag pro Sprint mit vereinbarter Teamkapazität | Planbar pro Sprint | Gering, wenn Kapazität definiert ist |
| Festpreis pro Release | Fixer Betrag für ein definiertes Release-Ziel | Planbar pro Release | Mittel |
| Festpreis gesamt mit Austauschregel | Fixer Gesamtpreis, Anforderungen gleichen Werts austauschbar | Planbar | Hoch, wenn Werte falsch geschätzt |
Die beiden klassischen Formen für Softwareentwicklung sind Festpreis und Time and Material; je kleiner der Umfang eines Festpreises, desto unproblematischer ist er — einen Festpreis je Sprint zu vereinbaren, ist viel unproblematischer als einen über zwölf Monate.[2] In der Schweizer Literatur wird zudem ein Modell beschrieben, bei dem Anforderungen zu Beginn zu Fixpreisen offeriert und zugleich ein Kostendach absolut oder prozentual vereinbart wird; der so definierte Kostenrahmen ergänzt den Fixpreis mit Elementen des Aufwandpreises.[1]
Werkvertrag oder Auftrag?
Im Zweifel hilft die Frage, wer das Risiko trägt, wenn ein Sprint sein Ziel nicht erreicht: Trägt es der Anbieter, spricht das für einen Werkvertrag, trägt es der Kunde, eher für einen Auftrag.
Die rechtliche Einordnung folgt den allgemeinen Regeln: Ist pro Sprint oder Release ein definiertes, prüfbares Ergebnis geschuldet, spricht das für Werkvertragsrecht; stellt der Anbieter ein Team zur Verfügung, das nach Weisung des Product Owners des Kunden arbeitet, spricht das eher für einen Auftrag. Die Grundlagen beschreibt das Kapitel Werkvertrag oder Auftrag.
Beide Varianten haben Folgen. Beim Auftrag gilt das zwingende jederzeitige Kündigungsrecht nach Art. 404 OR, das auch nicht über Konventionalstrafen eingeschränkt werden kann.[4] Beim Werkvertrag braucht es Abnahmekriterien, die zu einem iterativen Vorgehen passen. Ein Mischmodell — Rahmenvertrag mit Auftragscharakter, einzelne Releases als Werk — ist möglich, verlangt aber widerspruchsfreie Dokumente.
Was in einen agilen Vertrag gehört
| Klausel | Inhalt |
|---|---|
| Vorgehensmodell | Welche agile Methode, Sprintlänge, Zeremonien, Werkzeuge |
| Rollen | Product Owner auf Kundenseite mit Entscheidungsbefugnis, Team und Scrum Master auf Anbieterseite |
| Mitwirkungspflichten | Verfügbarkeit des Product Owners, Teilnahme an Reviews, rechtzeitige Entscheide |
| Backlog und Änderungen | Wer priorisiert, wie werden Anforderungen ergänzt oder ersetzt |
| Definition of Done | Wann ein Arbeitsergebnis als fertig gilt |
| Abnahme | Abnahme pro Sprint oder Release, Umgang mit nicht abgenommenen Stories |
| Vergütung | Modell, Kostendach, Abrechnung, Nachträge |
| Ausstieg | Beendigung nach einem Sprint, Übergabe von Code und Dokumentation |
| Rechte | Nutzungsrechte an Ergebnissen, auch bei vorzeitiger Beendigung |
Die Mitwirkung des Kunden ist in agilen Projekten zentral. Der Agile Leitfaden zu HERMES nennt die Bereitschaft des Fachs, einen Product Owner zu stellen, ausdrücklich als Voraussetzung für eine agile Umsetzung.[3] Fehlt diese Mitwirkung, sollte der Vertrag regeln, welche Folgen das für Termine und Kosten hat.
Abnahme im agilen Projekt
Statt einer grossen Abnahme am Ende gibt es in agilen Projekten viele kleine. Eine verbreitete Praxisregel lautet: Ein im Sprint Review nicht abgenommenes Arbeitsergebnis kommt zurück ins Backlog und wird für einen späteren Sprint eingeplant. Rechtlich lässt sich das als Teilabnahme abbilden. Wichtig ist, dass klar ist, was die Teilabnahme bedeutet: Beginnt damit die Rügefrist für diesen Teil? Gilt eine Gesamtabnahme am Ende? Ohne Regelung entsteht genau dort Streit.
- Definition of Done als vertraglichen Massstab festlegen.
- Teilabnahmen pro Sprint oder Release mit kurzem Protokoll dokumentieren.
- Regeln, ob und wann eine Gesamtabnahme stattfindet.
- Umgang mit Mängeln an bereits abgenommenen Teilen klären.
- Abnahme mit der Rechnungsstellung verknüpfen, wenn sinnvoll.
Wie Prüfung und Mängelrüge rechtlich funktionieren, zeigt das Kapitel Abnahme und Mängelrüge.
Agile Verträge mit der öffentlichen Hand
Für Anbieter heisst das konkret: Vorgehen, Rollen und Releaseplanung sind in der Ausschreibung oft selbst Zuschlagskriterien und sollten im Angebot entsprechend sorgfältig beschrieben werden.
Auch Verwaltungen setzen zunehmend auf agile Vorgehen. In HERMES ersetzt bei agiler Umsetzung die Phase Umsetzung die klassischen Phasen Konzept, Realisierung und Einführung; Releases werden mit Vorabnahme und Abnahme abgeschlossen.[3] Für Anbieter heisst das: Schon die Ausschreibung sollte erkennen lassen, ob agil gearbeitet wird, und das Vertragsmodell muss dazu passen. Wie die Beschaffung abläuft, beschreibt der Leitfaden Öffentliche Beschaffung Schweiz.
Kalkulation und Steuerung
Für Anbieter ist bei agilen Modellen die Teamkapazität die zentrale Kalkulationsgrösse: Wie viele Personen mit welchen Rollen arbeiten pro Sprint? Daraus ergibt sich der Preis pro Sprint. Für Kunden ist das Kostendach die zentrale Steuerungsgrösse: Wie viel darf das Vorhaben insgesamt kosten, und welche Ergebnisse sind bis dahin realistisch? Velocity und Releaseprognosen helfen beiden Seiten, früh zu erkennen, ob Umfang und Budget zusammenpassen. Für die Planung eignen sich die Rechner Sprintkapazität und Releaseprognose.
Ausstieg und Übergabe
Ein Vorteil agiler Vorgehen ist, dass nach jedem Sprint ein nutzbares Inkrement vorliegt. Verträge können das nutzen, indem sie einen geordneten Ausstieg nach einem Sprint oder Release vorsehen. Dann sind drei Punkte zu regeln: welche Vergütung für die laufende Periode geschuldet ist, welche Unterlagen und welcher Quellcode übergeben werden und welche Nutzungsrechte der Kunde an den bisherigen Ergebnissen erhält. Ohne Regelung droht beim vorzeitigen Ende genau dort Streit. Wie Rechte an Ergebnissen geregelt werden, beschreibt das Kapitel Urheber- und Nutzungsrechte.
Typische Fehler bei agilen Verträgen
- Ein Festpreis für einen offenen Umfang ohne Austausch- oder Änderungsregel.
- Ein Product Owner ohne Entscheidungsbefugnis oder ohne Zeit für das Projekt.
- Keine Regel, was eine Teilabnahme im Sprint Review bedeutet.
- Widersprüche zwischen Rahmenvertrag, Sprint-Vereinbarungen und Allgemeinen Geschäftsbedingungen.
- Keine Ausstiegsregel, sodass beim vorzeitigen Ende unklar ist, was übergeben wird.
- Ein Team nach Weisung des Kunden, ohne die Abgrenzung zum Personalverleih zu prüfen.
Viele dieser Fehler lassen sich mit einer strukturierten Prüfung vor Unterzeichnung vermeiden; die Checkliste Vertragsprüfung hilft dabei.
Ein Beispiel: Aufwand mit Kostendach
Ein Unternehmen lässt eine Kundenplattform agil entwickeln. Vereinbart werden zweiwöchige Sprints mit einem Team aus drei Entwicklern, einer Designerin und einem Scrum Master, Abrechnung nach Aufwand und ein Kostendach für das erste Release. Der Product Owner des Kunden priorisiert das Backlog und nimmt Ergebnisse im Sprint Review ab. Nähert sich der Aufwand dem Kostendach, entscheiden beide Seiten gemeinsam, ob der Umfang reduziert, das Dach erhöht oder das Release mit dem bisherigen Stand abgeschlossen wird.
Das Beispiel zeigt die Logik: Das Budget ist begrenzt, der Umfang beweglich, und die Entscheidungen fallen dort, wo das Wissen entsteht — im Review. Damit das funktioniert, braucht es Transparenz über den Verbrauch, etwa über eine Burn-up-Darstellung, und klare Regeln, was beim Erreichen des Dachs geschieht. Für die Auswertung hilft der Rechner Burn Rate.
Checkliste für den agilen Vertrag
- 1Vertragsmodell bewusst wählen: Aufwand mit Kostendach, Festpreis pro Sprint oder Release.
- 2Vorgehen, Rollen und Mitwirkungspflichten konkret beschreiben.
- 3Definition of Done und Abnahme pro Sprint oder Release regeln.
- 4Änderungs- und Priorisierungsprozess festlegen.
- 5Ausstiegsregeln mit Übergabe von Code und Dokumentation vereinbaren.
- 6Nutzungsrechte auch für vorzeitig beendete Projekte regeln.
- 7Rechtsnatur und Abgrenzung zum Personalverleih prüfen lassen.
Den Überblick bietet der Recht-Leitfaden; die Methode beschreibt das Profil Scrum.