Hinter den Worten „agiler Festpreis“ versteckt sich ein sehr interessanter Ansatz, um die Probleme mit den kommerziellen Aspekten von agilen Entwicklungsmethoden (z.B. Scrum) zu lösen. Das Problem steckt vorallem in den heute üblichen Verträge, die meistens einen fest definierten Funktionsumfang beschreiben und auf deren Grundlage die Schätzungen von Personentagen, dann ein Fixpreis berrechnet. Die Veränderung des Funktionsumfanges oder meiste daraus resultierenden Änderung der Personentage, führt immer zu einem unangnehmen Diskussionsbedarf. Der agile Festpreis bietet genau für dieses Problem mögliche Lösungswege an.
Grundliegendes Element für die Etablierung eines agilen Festpreis Vertrages zwischen den Vertragspartnern ist ein offenes und vertrauensvolles Verhältnis. Die Nutzung für ein solches Vertragswerk im Neukundenumfeld nur schwierig zu realisieren. Einfacher ist es mit Vertragspartnern die bereits miteinander Erfahrungen gesammelt haben. Der Kunde muss schließlich das Vertrauen zu den Prognosen des Anbieter haben, um bei den Verhandlungen des Vertragswerkes bereits sicher zu sein, dass das gewünschte Produkt am Ende der Entwicklung auch funktioniert.
Die Funktionsweise des agilen Festpreises beginnt in der Erarbeitung des Produkt Backlogs. In dieser Phase müssen Epics aufgenommen und nach und nach werden detailiert. Unter einem Epic verstehen man quasi einen bestimmten Themenblock, dem User stories zugewiesen werden. Als Beispiel für ein Epic könnten man eine User Verwaltung nennen und eine dazugehörige User story könnte die folgende sein: Als ein Benutzer möchte ich mich selbst registrieren können. Dieses Product Backlog erstellen die Vertragspartner am besten innerhalb von Workshops. Je nach Größe des Vorhabens können das auch mehrere Workshops sein, zumindest bis zu dem Punkt wo es keine neuen Ideen entstehen. In der Scrum Terminologie sind die Teilnehmer dieser Workshops meistens die sog. Stakeholder. D.h. der Personenkreis der bestimmt was das Product können soll. Wenn das Product Backlog nun existiert und soweit konkretisiert ist, dass das Scum Team mit den Schätzungen anfangen kann, dann muss das Product Backlog vor dem Hinzukommen neuer Epics geschützt werden. Jetzt muss das Scrum Team die einzelnen Stories schätzen und falls User Stories nicht fein genug detailiert wurde, ist der Product Owner gefragt, diese offenen Stories mit den Stakeholdern zu klären. Ob und wie eine User Story als „abarbeitbar“ definiert, nennt man Definition of Ready (DOR). Entspricht eine User Story nicht diesem Standard, wird das Team diese auch nicht in die Schätzung mit aufnehmen. Wenn das Scrum Team seine Arbeit beendet hat und alle Storypoints summiert sind, kann die nächste Phase der Vertragsverhandlungen beginnen. Die Vertragpartner kennen jetzt quasi den maximalen Funktionsumfang und die dafür nötigen Storypoints. Man kann quasi vergleichen, dass der eingangserwähnte fest definierte Funktionsumfang und die Schätzungen von Personentagen vorliegen. Nun muss der Anbieter nur noch den Geldwert für einen Storypoint nennen und schon kann man die Gesamtkosten der Produktentwicklung ausrechen. Wie kommt man jetzt aber an diesen Multiplikator? Hierfür muss die durschnittliche Verlocity eine Scrum Teams nehmen, durch die Anzahl der Teammitglieder teilen und mit dem typischen Internen Kostensatz für einen Mitarbeiter multiplizieren. Der Interne Kostensatz für Mitarbeiter benutzen viele Unternehmen bereits für die Berechung von Stundensätzen. Zusätzlich darf man nicht vergessen noch den den Gewinnen in dieser Rechnung mit auf zunehmen. Eine Beispiel Rechnung könnte so aussehen:
Durschnittliche Velocity des Teams ist 35
Das Team besteht aus 7 MitgliedernDer Interne Kostensatz liegt bei 70,- €
Der geforderte Gewinn liegt bei 100,-€
Daraus ergibt sich die Rechnung: 35 / 7 * (70 + 100) = 850,- €
Der Preis für einen Storypoint wird vertraglich fixiert und wird im Verlauf des Entiwicklungsprozess auch nicht verändert. Die Zahl sollte trotzdem kurz vor der Vertragsverhandlung berechnet werden, da sich die durschnitlliche Velocity im Verlauf eines Jahres verändern kann.
Im Verlauf dieser Phase der Vertragsverhandlungen wurde nun der Gesamtumfang und die Gesamtkosten des Entwicklungsvorhabens ermittelt. Weiterhin wird nun die Summe der Storypoints festgelegt, die das Scrum Team mindestens im Verlaufe jedes Sprints erreichen muss. Diese Festlegung erlaubt nun das Berechnen des spätesten Fertigstellungsdatum. Zusätzich kann diese Festlegungen nun dazu dienen, dass die Vertragspartner das Vorhaben vorzeitig beenden können. Wenn quasi die Lieferquote aus irgendwelchen Gründen nicht eingehalten werden kann, ist es den Vertragspartnern möglich den Vertrag zu kündigen.
Da nun der späteste Liefertermin bekannt ist, wird auch der Zahlungstermin definiert. Im besten Fall einigen sich die Vertragparteien auf die Zahlung von Sprints. D.h. immer wenn Teilabnahmen im Rahmen des Scrum Reviews Meetings durchgeführt wurde, wird eine Teilrechnung fällig. Die Vorteile dieser Methode liegt klar auf der Hand, der Lieferant hat keine lange Vorfinanzierung zu leisten und der Kunde erhält zeitnahe ein funktionierendes Inkrement des gewünschten Produktes.
Das Thema des agilen Festpreises ist sicherlich wesentlich umfangreicher als ich es hier in diesem Artikel darstellen kann. Es gibt am Markt Bücher die mehrere hundert Seiten starkt sind. Zusätzlich hat jedes Unternehmen eine andere Implementierung aus dem Scrum Framework. Somit muss auch die Implementierung des agilen Festpreises für jedes Unternehmen in angepasster Form durchgeführt werden. Trotzdem kann ich es aber sehr empfehlen, zu dem Thema zu recherchieren und zu prüfen ob man Methoden auf dem Gesamtkonstrukt anwenden möchte. Ich halte es für eine sehr interresante Variante, um die kommerziellen Probleme in der agilen Softwareentwicklung anzugehen.