• +49 (0) 731 7255 8870
  • sales@inno-on.de

Agile Projekte mit Festpreisbindung

Machen agile Projektmethoden und -Rahmenwerke es schwer, konventionelle Service Level Agreements anzuwenden?

Bereits 2015 hat Gardner eine Studie veröffentlich (#G00280983), derzurfolge konventionelle Sourcing-Ansätze agilen Projektlieferungen durch die komplexen und langen Verhandlungen im Wege stehen. Die langfristigen Vertragsvereinbarungen müssen trotz einer potentiellen Unzufriedenheit des Auftraggebers mit den Leistungen eines Service Providers fortgeführt werden. Die agilen Projektmethoden und -Rahmenwerke machen es schwer, konventionelle Service Level Agreements anzuwenden.

Welcher Weg aber führt um dieses Dilemma herum? Ist es möglich, agile Projektverträge zu Festpreiskonditionen zu vereinbaren und somit ein Projekt nach agilen Rahmenwerken (z.B. Scrum) in Sprints zu liefern, die Planung und Abrechnung aber nach einem klassischen Festpreismodell abzuwickeln?

Das funktioniert! Allerdings muss man sich darüber im Klaren sein, dass dies erst ab einer bestimmten Größenordnung von Projekten überhaupt sinnvoll und zur Zufriedenheit aller Vertragsparteien realistisch ist.

Ein agiler Projektvertrag zu Festpreiskonditionen bedeutet, dass das Projekt nach agilen Rahmenwerken (z.B. Scrum) in Sprints geliefert wird, die Planung und Abrechnung aber nach einem klassischen Festpreismodell erfolgt. Das Risiko nachträglicher Änderungen wird durch die Aufteilung des Projektes in Sprints geringgehalten. Voraussetzungen dafür sind natürlich die Einhaltung und Durchführung der Sprint Plannings, Sprint Reviews sowie festgelegte Sprint-Längen.

Vorab müssen der Scope sowie die Abnahmekriterien so genau wie möglich definiert werden, da es sich ja um eine Festpreisbindung handeln soll. In der agilen Welt wird erfolgt dies im Product Backlog, den User Stories[1] und den Epics[2].  Die Lieferung der Leistungen erfolgt dann im Rahmen zeitlich fest definierter Sprints. Für Werkverträge sicherlich ungewöhnlich ist hier die Beschreibung der Leistungen in User Stories.

Die Festpreisvereinbarung

Ein wesentlicher Unterschied zum klassischen Werkvertrag mit Festpreisbindung ist hier, dass die Festpreisvereinbarung sich immer auf einen Sprint bezieht: Die Bezahlung erfolgt, wenn die sog. Definition of Done (DoD[3]) für die im Sprint Backlog aufgenommenen Tasks erfüllt und das Ergebnis von Product Owner abgenommen wird. Der Preis errechnet sich dabei über die Story Points und den Wert pro Story Point. Der Wert pro Story Point kann nach Durchlauf mehrerer Sprints angepasst werden.

Der Product Owner verpflichtet sich, den Product Backlog mit ausreichend Inhalt zu füllen, so dass das Team ausgelastet werden kann.

Der Sprint Backlog liegt in der Verantwortung des Development Team. Dieses hat die Hoheit über die Items im Sprint Backlog. Nur das Development Team kann Änderungen des Sprint Backlog nach Absprache mit dem Product Owner durchführen (Vgl. Scrum Guide[4]).

Eine erfolgsbasierte Vergütung, bei der der Auftraggeber nur im Erfolgsfall (DoD für die Tasks des Sprint Backlogs wurde erreicht) die Vergütung freigibt, ist eine denkbare weitere Möglichkeit eines agilen Festpreisvertrages. Dies setzt allerdings eine sehr genaue Abschätzung der Aufwände (Story Points) und sehr genaue, von beiden Vertragsseiten gemeinsam abgestimmte, Abnahmekriterien (DoD) voraus. Die Erfahrung zeigt, dass dies eher schwer realisierbar ist, vor allem die Vorteile der Agilität verloren geht durch zeitlich aufwändige Abstimmungen über Produktlieferungen (User Stories, Increment), Aufwandsabschätzungen (Story Points) und den Abnahmekriterien - denn letztendlich muss das finanzielle Risiko vertretbar sein. Denkbar und sinnvoller sind hier Performance-bezogene Vergütungen (vorzeitige Zielerreichung, prozentuale Zielerreichung bezogen auf die Anzahl der User Stories des Sprints, etc).

Das agile Festpreisprojekt strebt eine zum Projektstart vollständige, wenn auch noch nicht detaillierte Beschreibung des Vertragsgegenstandes an. Die beiden Vertragspartner (Auftraggeber, Auftragnehmer) treffen gemeinsam Annahmen bezüglich des Geschäftswertes, des Umsetzungsrisikos, dem Aufwand und den Kosten. Auf Grundlage dieser Annahmen wird ein indikativer Festpreisrahmen vereinbart, der noch nicht bindend ist. Mitunter einer der wesentlichen Vorteile ist die Risikoteilung - beide Vertragsparteien tragen den Mehraufwand für ungeplante Änderungen mit. Es kann auch die Möglichkeit eines Vertragsausstiegs für beide Parteien (Ausstiegspunkte) vereinbart werden.

In einer Testphase (mehrere Sprints; Checkpoint-Phase) beginnt die erste Umsetzung. Am Ende dieser Phase wird aus der sog. Velocity[5] der durchschnittliche und tatsächliche Aufwand ermittelt und mit den vor Projektbeginn getroffenen Annahmen abgeglichen - die Vertragsbedingungen werden zu diesem Zeitpunkt festgelegt (Festlegung der Sprint-Festpreis-Baseline).

Ermittlung des Sprint-Festpreises

Für die Ermittlung des Festpreises werden folgende Kriterien zugrunde gelegt:

  • Die Beschreibung des Vertragsgegenstandes erfolgt auf einer groben Ebene (Projektziele, Themen, Anforderungen und User Stories/Epics)
  • Ein erfahrener Product Owner des Auftraggebers hat den Product Backlog in Absprache mit dem Scrum-Team initial erstellt.
  • Ein für das Projekt repräsentativer Epic oder mehrere User Stories werden ausgewählt (Referenz-User-Stories).
  • Mindestens zwei (2), aber maximal fünf (5) Sprints werden für die Ermittlung festgelegt.
  • In der Sprintplanung bestimmen die Vertragspartner anhand der Referenz-User-Stories mit Hilfe von Story Points die Komplexität für den Sprint (Planning Poker[6]). Zusätzlich wird eine Annahme bezüglich des Risikos bei der Implementierung sowie des Business-Values geschätzt. Daraus resultiert ein indikativer Festpreisrahmen, der noch nicht vertraglich bindend ist und erst in einem späteren Schritt (nämlich am Ende der Checkpoint-Phase) festgelegt wird.
  • Die Erfahrung zeigt, dass zwischen 5 und maximal 15 User Stories pro Sprint bewältigt werden können (Sprintlänge[7]: 2 Wochen). Dies bedeutet, dass die User Stories sehr gut vorbereitet werden müssen.
  • Die Sprint-Länge für die Test-Durchläufe sollte in der Checkpoint-Phase jeweils zwei (2) Wochen betragen. Dies deckt auch den zeitlichen Bedarf für das Sprint Planning, den Sprint Review sowie die Sprint Retrospektive ab.
  • Der Aufwand für die Checkpoint-Phase wird nach Aufwand (T&M) in Rechnung gestellt.
  • Das Development Team wird aus unterschiedlichen Rollen der Innovations ON zusammengesetzt (die Rollen haben unterschiedliche Tagessätze[8]).
  • Es wird eine Checkpoint-Phase (Testphase) festgelegt und mit der Umsetzung begonnen. 

o   Hieraus werden empirische Erkenntnisse bezüglich der sog. Sprint Velocity (Anzahl erfolgreicher Story Points pro Sprint) gewonnen. 

o   Wir empfehlen eine Länge von mindestens zwei (2) und maximal fünf (5) Sprints mit einer Dauer der Sprints von zwei (2) Wochen (time-boxed[9]). 

o   Es wird der arithmetische Mittelwert der Velocity der Sprints gebildet. Zusätzlich wird das arithmetische Mittel für die Kosten (Summe Tagessatz pro Rolle und Personentag) festgestellt. Dadurch werden die Kosten pro Story Point für erfolgreich gelieferte Product Increments errechnet und mit zuvor getroffenen Annahmen überprüft und ggf. angepasst. Diese stellt die Baseline des Sprint-Festpreises dar.

o   Abschließend wird der Festpreisrahmen vertraglich bindend festgelegt. Ebenso wird die Verteilung der Risiken vereinbart (In welchem Umfang werden entstandene Kosten bei Überschreitung des Maximalpreisrahmens an den Auftraggeber verrechnet? Erfolgt eine Incentivierung bei Unterschreitung der erwarteten Velocity?)

  • Nach jeweil vier (4) Sprints werden erneut die Velocity und der mittlere Aufwand (basierend auf den Innovations ON-internen Tagessätzen) kalkuliert. Die Abweichung zur Baseline wird bestimmt und ggf. eine Preisanpassung durchgeführt.

Eine sinnvolle Erweiterung des Vertrages stellt die 60-40-20-Regelung dar, durch die eine gewisse Flexibilität in Form eines Kapazitätenpuffers[10] hinzugefügt wird. Diese Regelung teilt den Backlog und den Projektumfang in eine 60%, 40% und 20% Prioritätenliste auf. Die Kategorie 60% bedeutet “Muss”, 40% bedeutet “Möchte” und 20% bedeutet “Stretch Goal”. Die Elemente der Kategorie 60% sind auf alle Fälle zu liefern. Die Elemente der Kategorie 40% sind ebenfalls zu liefen, allerdings mit einem gewissen Verhandlungsspielraum (Tausch gegen andere im Rahmen des Change-Managements). Die Summe der Elemente dieser beiden Kategorien stellen den “in-scope backlog” dar. Bei den Elementen der Kategorie 20% handelt es sich um Elemente, die dann bearbeitet werden, wenn der “in-scope backlog” frühzeitig fertiggestellt wurde.

Die Sprintlänge(n)

In der Regel und nach dem Scrum-Framework ist erst nach Durchlauf einiger Sprints feststellbar, welches eine optimale Sprintlänge ist. Als Grundlage kann man wählen: Je mehr Probleme es im Ablauf der Prozesse gibt, desto sinnvoller ist ein kürzerer Sprint-Zyklus. Insbesondere zu Beginn eines neuen Projektes (oder auch der Zusammenstellung eines neuen Scrum-Teams) beträgt die optimale Sprintlänge eine (1) Woche. Grundsätzlich kann die Länge der Sprints in der Sprint Retrospektive korrigiert werden.

Je genauer die User Stories definiert werden können, desto länger kann der Sprint ausfallen.

Das Scrum-Team

Letztendlich ist die Erfahrung des Scrum-Teams ausschlaggebend für die Festlegung der Sprintlänge - diese darf unter keinen Umständen von den Stakeholdern vorgegeben werden. Je erfahrener ein Scrum-Team ist, desto länger kann der Sprint sein.

Wichtiger Bestandteil zur Steuerung des Projektes ist die Benennung und Besetzung der projektverantwortlichen Rollen: Projektmanager[11] und Product Owner sowie der Scrum Master. Aus diesen Rollen bildet sich der Lenkungskreis, der dafür Sorge trägt, dass der kontinuierliche Spezifikationsprozess funktioniert und die jeweils an den höchsten priorisierten Anforderungen als User Stories festgelegt werden. Das Scrum-Team besteht immer aus einem (Teilzeit)-Scrum Master, einem Product Owner und zwischen drei (3) und neun (9) Developern.

Eine wesentliche Voraussetzung für die erfolgreiche Lieferung der Produkte aus dem Product Backlog ist ein erfahrenes Scrum-Team. Wir gehen dabei von einer Erfahrung in der agilen Projektarbeit von mindestens zwei (2) Jahre für alle Projektmitglieder aus.

Der Scrum Master ist mitunter verantwortlich im Rahmen der Sprint Retrospektive die Notwendigkeit für Schulungsmaßnahmen (Scrum Framework) festzustellen und entsprechende Maßnahmen zu treffen. Letztendlich ist das Development Team eigenständig verantwortlich für die Mitteilung notwendiger Maßnahmen im Rahmen der Sprint Retrospektive.

Das Projektende

Bei agilen Festpreisprojekten gilt das Projekt als beendet, wenn der Auftraggeber den erwarteten Nutzen durch die bereits erfolgten Lieferungen als erfüllt abnimmt. Eine Verweigerung der Abnahme trotz Erreichen der zuvor gemeinsam definierten DoD (Definition of Done) sollte ausgeschlossen werden.

Offene Aufgaben aus dem Backlog den beendeten Sprints werden wieder in den Product Backlog übertragen. Im anschließenden Sprint Review wird erneut geprüft, für welche User Stories Aufgaben in den Sprint Backlog übertragen werden. Der Product Owner entscheidet über die Priorisierung der User Stories/Epics, aber auch darüber, ob User Stories dem Product Backlog neu hinzugefügt oder herausgenommen werden. 

Eine vorzeitige Beendigung eines Sprints

Sollte ein (oder auch mehrere) bereits geplante(r) Sprint(s) vor deren Start abgesagt werden, so fällt in der Regel eine Pauschale (z.B. 20%) für den geplanten bzw. ausgefallenen Umsatz an (Cancellation Fee[12], siehe Fußnote 12). Dabei muss eine vertragliche Vorlaufzeit für den Change Request festgelegt werden (z.B. 4 Wochen).

Änderung/Neuaufstellung des Development Teams

Muss das Development Team aufgrund neuer oder geänderter Anforderungen im Product Backlog neu aufgestellt oder angepasst werden (neue, ungeplante Anforderung wie z.B. Spezialwissen), so muss auch dies mit einer entsprechenden Vorlaufzeit bedacht werden. Tritt durch eine schlechte Planung des Backlog oder zu spät aufgesetzte Change Requests eine Minderauslastungen des Development Teams ein, so sollte dies dem Vertragspartner in Rechnung gestellt werden[13].

 

[1] Eine User Story („Anwendererzählung“) ist eine in Alltagssprache formulierte Anforderung. "Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> zu erreichen."

[2]  Unter einem Epic versteht man eine große User Story, die nicht einfach beschrieben werden kann.

[3] Die "Definition of Done" (DoD) ist eine Liste von Fertigstellungskriterien, die das Development-Team zur Erstellung des Produktes zu beachten hat. Die Hoheit über die "DoD" liegt beim Development-Team.

[4]  Scrum Guide: https://www.scrumguides.org/scrum-guide.html#events-planning

[5] Die Velocity ist der Durchschnitt über die Summen aller vom Team erledigten Story Points pro Sprint. Im Grunde zeigt die aktuelle Velocity die aktuelle Geschwindigkeit in der Umsetzung innerhalb eines Sprints an. Es gibt also eine aktuelle Velocity und eine durchschnittliche Velocity pro Sprint.

[6] Planning Poker (auch als Scrum Poker bezeichnet) ist eine spielerische Team-Building-Aktivität zur Erreichung von Konsens in Bezug auf die Aufwandsschätzung innerhalb einer Gruppe von agilen Projekten.

[7] Dieser Wert wird im Rahmen der initialen Planung zwischen den Vertragsparteien besprochen und definiert.

[8] Cloud Engagement Manager, Cloud Architect, Cloud Systems Developer, Cloud Software Engineer, etc.

[9] Eine Time-Box ist ein Zeitabschnitt, der nicht unter- oder überschritten werden darf und in dessen Grenzen Meetings oder Entwicklungs-Inkremente ablaufen. Die Time-Box ist eines der grundlegenden Konzepte in Scrum und trägt maßgeblich zur Effizienz des Prozesses bei.

[10] Capacity Buffer: Typischer Weise wird jedem Projekt ein gewisses Puffer zugerechnet. Man unterscheidet zwischen Projekt-, Versorgungs-, Ressourcen- und Kapazitätspuffer. 

[11] Wozu ein Projektmanager in agilen Umfeldern? Vgl. https://www.vdi-wissensforum.de/news/der-agile-projektmanager/

[12] Vgl. J. Sutherland, "Agile Contracts: Money for Nothing and Change for Free."

[13] Ein Beispiel hierfür ist der ungeplante notwendige Einsatz eines Entwicklers an Stelle eines geplanten Architekten - der Entwickler muss ggf. aus einem anderen Projekt gelöst werden, während der Architekt “auf die Schnelle” nicht in einem anderen Engagement untergebracht werden kann.

  • Gelesen: 710
Copyright by Innovations ON GmbH

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.