Einer der vier Grundwerte des agilen Manifests ist: Customer collaboration over contract negotiation. Dies könnte darauf hindeuten, dass Verträge bei agilen Projekten keinen großen Stellenwert mehr haben. Stimmt dies tatsächlich? Um Rechtssicherheit und eine Leitlinie bei der Entwicklung zu haben sind auch bei agilen Projekten Verträge unentbehrlich – nur weichen diese oft im Aufbau und der Handhabung von denen in „normalen Projekten” ab. Dieser Artikel gibt Ihnen eine Übersicht über die Charakteristik agiler Verträge und erklärt Ihnen die verschiedenen Vertragsarten, ihren Zweck und wie diese angewendet werden.
Agile Verträge brauchen mehr Flexibilität
In diesem Artikel haben Sie die vier Grundwerte des agilen Manifests kennengelernt. Einer davon ist: Customer collaboration over contract negotiation. Dies könnte darauf hindeuten, dass Verträge bei agilen Projekten keinen großen Stellenwert mehr haben. Stimmt dies tatsächlich?
Viele interpretieren agile Entwicklung vereinfacht so: Der Auftraggeber definiert ein Budget und dann entwickelt der Auftragnehmer so viele Funktionalitäten, bis das Budget aufgebraucht ist. Wir passen die Lieferung von Softwarekomponenten den sich ändernden Kundenwünschen und Umfeld an und sind sicher, dass der Kunde am Schluss das erhält, was er sich vorgestellt hat, bzw. braucht – vielleicht sogar mit etwas Dokumentation. So einfach ist es aber auch bei agilen Projekten nicht.
Wir entwickeln, bis das Budget aufgebraucht ist – wirklich?
Bei der traditionellen Softwareentwicklung (z.B. nach dem Wasserfallmodell) sind beim Start des Projektes die Anforderung größtenteils bekannt und damit sind auch die Kosten und Termine besser kalkulierbar. Bei agilen Projekten hingegen sind die Anforderungen zu Beginn des Projektes oft nur zum Teil bekannt und sie können sich während der Projektdurchführung jederzeit ändern. Aber auch bei agilen Projekten will der Kunde bzw. Auftraggeber wissen, was sein Projekt ungefähr kostet und was er für sein Geld erhält. Dies macht die Vertragsgestaltung natürlich einiges anforderungsreicher.
Verträge bei agilen Projekten sollten deshalb grundsätzlich mehr Flexibilität bieten und auch den Umstand von noch unbekannten und sich ändernden Anforderungen berücksichtigen.
Verträge, die für traditionelle Projekte geeignet sind, sind deshalb nicht automatisch sinnvoll für agile Projekte. In den folgenden Abschnitten gebe ich Ihnen einen kurzen Einblick in die Vertragsgestaltung bei der agilen Softwareentwicklung. Zuerst zeige ich Ihnen, welchen Zweck Verträge erfüllen und was für Vertragsformen es gibt und wie sich diese an der Art der Entwicklung orientieren.
Der Zweck von Verträgen
Verträge definieren rechtsgültige Vereinbarungen zwischen Auftraggeber und Auftragnehmer und sollen festhalten und nachprüfbar machen, was die Parteien miteinander abgemacht haben. Sie sollen Rechtssicherheit für die Vertragspartner schaffen bezüglich der gegenseitigen Rechten und Pflichten. Damit wird auch implizit oder explizit geregelt, wer welche Risiken trägt. Weicht eine der Parteien von diesen Vereinbarungen ab, kann die andere Partei auf Einhaltung der Vereinbarung klagen, Zahlungen verweigern oder auf Schadensersatz bestehen.
Bei agilen Projekten verfolgen Auftraggeber mit Verträgen folgende Ziele:
- Eine Roadmap vorgeben
- Risiken minimieren
- Rechtssicherheit haben
Verträge im Geschäfts- und Privatleben sind dazu da, um sich zu vertragen und dies ist auch im Projektgeschäft und bei agilen Projekten so. Verträge müssen keine Bücher sein, aber ohne Verträge haben Sie keine Rechtssicherheit und so können Unsicherheiten und Unzufriedenheit entstehen.
Verträge sind dazu da, um sich zu vertragen.
Die Anforderungen sind zu Projektbeginn nur zum Teil bekannt
Bevor ein traditionelles Projekt startet, analysiert der Auftraggeber seinen Bedarf und erstellt auf dieser Basis ein Lastenheft mit den Anforderungen an die zu entwickelnde Software. Dieses dient auch oft dazu, um bei Ausschreibungen den günstigsten oder bestgeeigneten Anbieter zu finden.
Der Auftragnehmer erstellt auf Basis des Lastenheftes ein Pflichtenheft, in dem beschrieben ist, wie er die Anforderungen umsetzen werden. Nachdem das Pflichtenheft durch den Auftraggeber freigegeben wurde, beginnt der Auftragnehmer mit der Umsetzung. Das Ergebnis wird vom Auftraggeber abgenommen, wenn es die Anforderungen aus dem Lastenheft erfüllt. Bei agilen Projekten sieht dies etwas anders aus.
Agile Entwicklung adressiert komplexe Problemstellungen, die sich per Definition vorab nicht vollständig analysieren und spezifizieren lassen. Die Beteiligten erkennen oft erst im Projektverlauf, wie bestimmte Teile/Funktionalitäten der Software zu gestalten sind, damit der erhoffte Geschäftsnutzen erzielt wird. Es kann auch sein, dass sich die Bedürfnisse des Kunden oder das Business-Umfeld so verändert, dass neue Anforderungen gefragt sind, Anforderungen geändert werden müssen oder entfallen – und genau dafür wird ja agile Entwicklung eingesetzt.
Verträge sollten eigentlich etwas Abgemachtes, an was man sich später halten muss, klar definieren, und somit Sicherheit geben. Bei agilen Projekten muss ein Vertrag es jedoch ermöglichen, Softwarefunktionen zu entwickeln, die bei Vertragsabschluss nur zum Teil bekannt sind, noch unbekannt sind oder sich während der Projektabwicklung ändern. Das macht die Vertragsgestaltung einiges anforderungsreicher.
Agile Verträge brauchen mehr Flexibilität.
Die agile Vertragssicht
Aus rein ökonomischen Gründen sollte man erst gar nicht viel Aufwand in die detaillierte Beschreibung von Funktionen investieren, die man später anders oder gar nicht benötigt. Werden Funktionen im Vertrag beschrieben, sollten diese grobgranular sein oder nur exemplarischen Charakter haben.
Bei der Vertragsgestaltung sollten Sie vor allem folgende drei agilen Grundideen berücksichtigen:
- Unvollständige Funktionsbeschreibung: Wir wissen zu Projektbeginn noch nicht vollständig, wie die Software aussehen muss, um den erhofften Nutzen zu bringen.
- Gemeinsames Verständnis: Wir erzeugen ein gemeinsames Verständnis über Gespräche und nicht über Dokumente.
- Kooperative Problemlösung: Wir reagieren auf Probleme mit größerer Nähe und enger Zusammenarbeit.
Je weniger im Vertrag über zu liefernde Funktionalitäten steht desto einfacher kann man sich ändernden und neuen Anforderungen anpassen, aber es erhöhen sich auch die Kosten- und Terminrisiken und die Risiken bei rechtlichen Streitigkeiten.
Das agile Vorgehen beeinflusst die Vertragsgestaltung, bei der Sie verschiedene Kriterien berücksichtigen müssen. Wichtig ist z. B. die Vertragsart selbst. Im nächsten Abschnitt lernen Sie deshalb den Festpreis-Vertrag, Time & Material Vertrag und nutzenorientierte Vertragsarten kennen.
Sie müssen auch die anzuwendende agile Entwicklungsmethode im Vertrag erwähnen (z. B. Scrum). Ein Verweis auf den Scrum Guide als offizielle Scrum-Definition reicht dafür aus.
Festpreis oder Time & Material Vertrag?
Üblich in der Softwareentwicklung sind Festpreis oder Time & Material Verträge. Festpreis bedeutet: Der Auftraggeber bezahlt einen festen Preis für einen klar definierten Projektumfang. Time & Material bedeutet: Der Auftraggeber bezahlt regelmäßig die erbrachten Aufwände nach einem vorher vereinbarten Tagessatz.
Bei einem Festpreis-Vertrag können Sie den vorab definierten Funktionsumfang nur sehr aufwendig ändern. Bei Time & Material werden Sie bei agilen Projekten in der Regel den Funktionsumfang vorab grob skizzieren, diesen aber nicht zwingend vertraglich fixieren. Damit ist der Auftraggeber maximal flexibel, kann während des Projektes hinzuzulernen, wie die Software ausgestaltet werden muss, hat aber die meisten Risiken auf seiner Seite.
Werkverträge (Unterschied Werkvertrag/Dienstvertrag) erfordern nicht zwangsweise Festpreisverträge. Die Zahlung kann auch über Time & Material erfolgen. Ob es sich um einen Werk- oder Dienstvertrag handelt, hängt nicht primär von der Bezahlung ab, sondern von den gegenseitigen Rechten und Pflichten, die im Vertrag festgehalten sind. Nutzenorientierte Verträge sind eine weitere Art von Verträgen.
Time & Material und Festpreis sind kostenorientierte Verträge. Sie thematisieren nur die Kosten. Nutzenorientierte Verträge binden die Bezahlung an den generierten Nutzen, sind flexibler und passen eigentlich besser zur agilen Denkweise als kostenorientierte Verträge.
Mehr Vertrauen bedeutet weniger Vertrag
Wie vollständig bzw. umfangreich ein Vertrag sein muss, hängt maßgeblich auch vom Vertrauensverhältnis zwischen Auftraggeber und Auftragnehmer ab. Haben Sie mit diesem Auftragnehmer schon einmal zusammengearbeitet? Haben Sie das Vertrauen, dass der jeweilige Auftragnehmer bei Problemen zu einer kooperativer Lösungsfindung bereit ist?
Festpreisverträge bei agilen Projekten
Bei Festpreis-Verträgen versucht der Auftraggeber normalerweise einen möglichst umfangreichen und hochqualitativen Lieferumfang für möglichst wenig Geld zu erhalten. Der Anbieter hingegen versucht mit möglichst wenig Aufwand seinen vertraglichen Verpflichtungen zu erfüllen. Das heißt, die Interessen sind entgegengesetzt, was zu Konflikten führen kann.
Deshalb könnte man meinen das Time & Material-Verträge besser zu agiler Entwicklung passen. Dies stimmt, aber auch Time & Material-Verträge sind nicht ohne Probleme. Wenn sich z. B. das vom Auftragnehmer gestellte Entwicklungsteam nicht so verhält, wie vom Auftraggeber gewünscht. Der Auftraggeber erwartet von einem agilen Entwicklungsteam z. B.:
- dass es sich in die Softwaregestaltung einbringt, sodass das Produkt den erhofften Nutzen schafft,
- dass es Hindernisse selbst beseitigt und
- dass es über Retrospektiven die Zusammenarbeit und die Prozesse verbessert und so schrittweise effektiver wird.
Change for free
Das „Change for free“ Konzept wird bei Festpreisverträgen hauptsächlich angewendet, um während der Vertragsabwicklung Änderungen einfließen zu lassen. Dieses Konzept definiert folgenden Regeln:
- Änderungen in der Priorität der Features sind „free“, wenn sich der Total-Vertragswert nicht ändert.
- Neue Features können „free“ vor Sprintbeginn den Sprints hinzugefügt werden, wenn Features mit niedriger Priorität und gleichem Aufwand entfernt werden.
Nutzenorientierte Verträge
Aus agiler Sicht sind nutzenorientierte Verträge interessant, da in der agilen Entwicklung der Auftraggeber und Auftragnehmer gemeinsam an einem Produkt arbeiten mit möglichst großem Business-Value, zu möglichst geringen Kosten. Nutzenorientierte Verträge sind in der Softwareentwicklung noch nicht so üblich, könnten aber mit der agilen Entwicklung mehr an Bedeutung gewinnen, denn diese Art von Verträgen hängen den Nutzen an die Vergütung und setzen deshalb einen größeren Anreiz an die Optimierung des Nutzens. Zu den nutzenorientierten Verträgen gehören zum Beispiel folgende Varianten:
- Proviant & Prämie
- Money for Nothing
- Profit-Sharing
- Pay per Use
Proviant & Prämie
Proviant & Prämie Verträge enthalten kostenorientierte als auch nutzenorientierte Anteile. Diese Art von Verträgen lehnt sich an den Cost-Plus, bzw. Cost-plus-incentive fee (CPIF) Verträge an.
Der Auftraggeber zahlt einen niedrigen Tagessatz nach Aufwand, der die Kosten des Auftragnehmers deckt, aber keinen Gewinn abwirft. Der Auftragnehmer bekommt damit den Proviant, den er zum Überleben benötigt. Wenn ein vereinbartes Ziel erreicht wird, erhält der Auftragnehmer eine Prämie.
Bei Proviant & Prämie möchte der Auftragnehmer das Ziel möglichst schnell mit wenig Aufwand erreichen. Dann ist sein Gewinn am höchsten. Aber auch der Auftraggeber ist interessiert das Ziel schnell zu erreichen, damit er wenig Proviant bezahlt und so seine Gesamtkosten reduziert.
Proviant & Prämie Verträge sorgen für gleichgerichtete Interessen zwischen Auftraggeber und Auftragnehmer. Diese Vertragsart kann ein Zwischenschritt sein, um von kostenorientierten zu nutzenorientierten Verträgen zu gelangen.
Den Nutzen zu bestimmen ist eine Herausforderung bei allen nutzenorientierten Verträgen. Der Auftraggeber und der Auftragnehmer müssen ein klares Verständnis über den zu erbringen Nutzen haben. Auch muss der Auftragnehmer bereits gute Kenntnisse des Fachbereichs des Auftraggebers haben.
Money for Nothing
Die “Money for Nothing”-Strategie wird bei Festpreisverträgen angewendet. Dieser agile Vertrag ermöglicht die vorzeitige Beendigung des Vertrages, wenn z. B. der Wert der Features unter ein ROI-Kriterium (Return On Investment) fällt. Der Vertrag ermöglicht es dem Auftraggeber, 80% seines verbleibenden Auftragswertes einzusparen, indem er dem Auftragnehmer 20% des verbleibenden Auftragswertes als Gegenleistung (oder Prämie) bezahlt, wodurch die Marge eines agilen Auftragnehmers von z. B. 15-20% auf 50-80% steigen kann.
Profit Sharing Verträge
Bei »Profit Sharing« Verträgen ist der Auftragnehmer am Nutzen, den die Software generiert beteiligt – während der Entwicklung erhält er aber keine Zahlung für seinen Aufwand. Damit ist natürlich der Auftragnehmer sehr interessiert, wie er diesen Nutzen am besten generieren kann. Je schneller und je besser der Nutzen erreicht wird, desto größer ist sein Umsatz. Für den Auftraggeber sinkt dagegen das Projektrisiko. Bei einem Profit-Sharing-Projekt kann für den Auftraggeber der ROI (Return on Investment) kaum negativ werden. Auch bei dieser Vertragsform ist keine detaillierte Feature-Liste oder genaue Kostenabschätzung für den Vertrag notwendig. Die Risiken liegen hier zu einem großen Teil auf der Seite des Auftragnehmers.
»Pay per Use« Verträge sind eine Spezialform von Profit-Sharing-Verträgen. Hier wird nicht für den direkten Nutzen bezahlt, sondern für die Nutzungshäufigkeit bestimmter Funktionen. Diese Art von Verträgen passt z. B. für Software as a Service (SaaS).
Für jeden Sprint oder Release einen Vertrag?
Wenn der Umfang eines Festpreises sehr klein ist, verringern sich auch Risiken. Je Sprint (oder Release bei kurzen Sprints) einen Festpreis zu vereinbaren, ist weniger risikoreich als z. B. ein Festpreis über 12 Monate. Diese Strategie hat aus meiner Sicht viele Vorteile und bedeutet nur wenig Mehraufwand in der Vertragsadministration.
Beim Festpreis pro Sprint wird das Projekt als Abfolge vieler kleiner Festpreisprojekte durchgeführt. Das Ergebnis der Sprint-Planung ist jeweils ein eigener Festpreisvertrag. Im Sprint-Review erfolgt dann die Abnahme.
Dies könnte etwa so aussehen:
- Einen Vertrag, um einen größeren Anforderungsworkshop durchzuführen (auch, um den Auftragnehmer besser kennenzulernen). Dies kann zu einem Go/no-go mit diesem Auftragnehmer führen.
- Ein Rahmenvertrag, der die grundsätzlichen Aspekte der Zusammenarbeit im Voraus regelt und ein zusätzlicher Vertrag für die ersten beiden Sprints.
- Weitere Verträge für zusätzliche Sprints oder kurze Release.
Mit diesem Vorgehen weiß der Auftraggeber, was er nach jedem Sprint für sein Geld bekommt. Gleichzeitig kann er in jedem Sprint flexibel auf neue oder geänderte Anforderungen reagieren. Wenn der Auftraggeber die Velocity des Entwicklungsteams bei jedem Sprint misst, so kennt er auch die ungefähren Kosten jedes Sprints und kann eine Prognose für die Gesamtprojektkosten erstellen.
Bei dieser Strategie ist es auch sinnvoll für eine Vorprojektphase mit einen Anforderungsworkshop mit einem Auftragnehmer einen Festpreisvertrag abzuschließen. Dies kann auch mit mehreren potenziellen Auftragnehmern gemacht werden, um einen Auftragnehmer zu evaluieren.
Wer macht den Vertrag?
In größeren Unternehmen erstellen oft Fachleute aus der Einkaufsabteilung Projektverträge. Nach meiner Erfahrung sind diese Personen jedoch mit Projektverträgen und speziell mit Verträgen für agile Projekte oft überfordert. Deshalb ist es sinnvoll, wenn sich der Product Owner, der sinnvollerweise vom Auftraggeber gestellt wird, sich mit agilen Verträgen auskennt und die Einkaufsabteilung entsprechend unterstützen kann.
Fazit
Verträge sind auch bei agilen Projekten wichtig. Die Gestaltung des Vertragswerkes ist abhängig von der zu erstellenden Software, der bereits geleisteten Vorarbeit und dem bereits definiertem Scope, aber auch wie der Nutzen der Software in die Vertragsgestaltung einfließen soll. Agile Verträge brauchen mehr oder weniger Freiraum, um sich an ändernde Bedingungen anpassen zu können. So entstehen neue Möglichkeiten. Die Risiken, die durch diesen Freiraum in der Zusammenarbeit jedoch entstehen, müssen die Vertragsparteien berücksichtigen.
Was haben Sie für Erfahrungen mit Verträgen bei agilen Projekten gemacht? Stimmen Sie mit meinen Aussagen überein oder haben Sie eine andere Ansicht oder Ergänzungen? Teilen Sie Ihre Erfahrung mit mir und den Lesern unten in der Kommentarbox. Danke!
Wollen Sie mehr erfahren, wie Sie Ihre agilen Projekte mit Scrum noch erfolgreicher machen? Mein Buch „Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden“ bringt Sie einen wichtigen Schritt weiter!
