Lesedauer: ca. 7 Minuten
Lesedauer: ca. 7 Minuten
Das funktioniert! Allerdings müssen Sie 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, wie 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 gering gehalten. Voraussetzungen dafür sind 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 und den Epics. Der Product Backlog enthält alle Anforderungen an das Produkt, wie beispielsweise die Kundenwünsche und -anforderungen. Die User Stories beschreiben diese Anforderungen und umfasst meist nicht mehr als ein bis zwei Sätze, während die Erics im Kontrast dazu alle wichtigen Details umfassen.
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.
Ein wesentlicher Unterschied zum klassischen Werkvertrag mit Festpreisbindung ist hier, dass die Festpreisvereinbarung sich immer auf einen Sprint bezieht: Die Bezahlung erfolgt, wenn die so genannte. Definition of Done (DoD) 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 Entwicklungsteams. 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.
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 so genannten Velocity 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).
Für die Ermittlung des Festpreises werden folgende Kriterien zugrunde gelegt:
Hieraus werden empirische Erkenntnisse bezüglich der sog. Sprint Velocity gewonnen. 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.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). 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. 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 jeweils 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 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.
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.
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 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.
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.
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). Dabei muss eine vertragliche Vorlaufzeit für den Change Request festgelegt werden (z.B. 4 Wochen).
Muss das Entwicklungsteam 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 Entwicklungsteams ein, so sollte dies dem Vertragspartner in Rechnung gestellt werden.