Mit unserer Agile Software Factory entwickeln wir Individualsoftware zum Festpreis. Immer wieder kommt es zu Diskussionen: Geht das überhaupt? Widersprich das nicht den agilen Grundsätzen? Wir denken nicht, dass sich Festpreis und Agilität widersprechen und ich werde hier versuchen zu argumentieren warum. Ganz im Gegenteil glaube ich sogar, dass Festpreise nur dann zu Zufriedenheit bei Kunden und Lieferanten führen, wenn man agil zusammen arbeitet.
Veränderte Schwerpunkte
Das grundsätzliche Problem mit Festpreisprojekten ist, dass in den meisten Fällen eben nicht nur der Preis fest sein soll, sondern auch der Inhalt und der Termin. Dies wird im Projektmanagement gerne auch „Magisches Dreieck “ genannt. Das Management dieser drei Zielgrößen führt in klassischen Festpreisprojekten zu Problemen, die ich in meiner Vergangenheit schon sehr häufig selbst mit erlebt habe:
- Der Kunde erhält genau das, was er im Pflichtenheft aufgeschrieben hat. Jegliche Abweichungen werden über das „Change Management“ entweder abgelehnt oder man lässt sich die Änderungen teuer bezahlen. Viele Kalkulationen von Festpreisen gehen schon beim Angebot davon aus, dass das Projekt nur über die Änderungen profitabel wird. Nicht nur, dass der Kunden nicht das erhält was er möchte, es geht auch viel Zeit und Energie in Meetings verloren, in denen man diskutiert, ob etwas ein Change ist oder nicht.
- Qualität und nichtfunktionale Anforderungen werden meistens nur rudimentär oder garnicht spezifiziert. Dadurch fallen diese fast immer der Zeit und dem Budget zum Opfer und am Ende stimmt dann die Performance nicht oder der übergebene Sourcecode ist nur schwer weiter zu pflegen und zu ändern.
- Der Geschäftswert und die Kundenzufriedenheit spielen in klassischen Projekten kaum eine Rolle. Anforderungen werden nicht priorisiert, weil sowieso „alles“ umgesetzt werden muss und die Endanwender werden meistens am Tag der Einführung mit der neuen Software konfrontiert – alles andere hätte nur den Zeitplan durcheinander gebracht und zu unnötigen Changes geführt.
Für Agile Projekte erweitern wir das magische Dreieck also um drei weitere Kerngrößen: Kundenzufriedenheit, Geschäftswert und Qualität. Man kann auch sagen, dass in klassischen Ansätzen das Projekt „Plan getrieben ist“, während agile Projekte „Wert getrieben“ sind und versuchen in jeder Interation den maximalen Wert für den Kunden zu erzielen. (Priorisierung)
An Hand dieses „Magischen Hexagon“ sieht man auch wo der agile Ansatz sich in Festpreisprojekten seine Flexibilität erhält: Beim Umfang. Während bei klassischen Festpreis Projekten der Umfang vorab fest definiert wird, ist bei agilen Festpreisen nicht 100%ig definiert, was der Kunden am Ende für den festen Preis erhält. Was sich auf den ersten Blick wie ein „KO“ Kriterium anhört, entpuppt sich auf den 2. Blick als einzige realistische Form der Zusammenarbeit bei einem festen Preis, wenn man am Ende auch Qualität, Kundenzufriedenheit und Geschäftswert maximieren möchte.
Die Diskussion möchte ich mit drei Thesen starten:
For a new software system, the requirements will not be completely known until after the users have used it.
Aus dem Buch A Discipline for Software Engineering von Watts Humphrey – der auch „Vater der Software Qualität“ genannt wird.
Uncertainty is inherent and inevitable in software development processes and products.
Aus der Veröffentlichung The Uncertainty Principle in Software Engineering von Hadar Ziv, Debra J Richardson, und Rene Klosch.
An interactive system can never be fully specified nor can it ever be fully tested.
Von Peter Wegener – wird auch Wegener’s Lemma genannt.
Was möchte ich damit sagen? Man kann in einem überschaubaren Aufwand keine Software zu 100% spezifizieren! Seit 1999 arbeite ich in Projekten und sehe immer wieder, dass dies aber auch heute noch versucht wird und der Drang nach „Sicherheit“ dazu führt, dass Pflichtenhefte mit hunderten Seiten spezifiziert werden – persönlich habe ich aber noch nie erlebt, dass diese Spezifikationen auch nur nahe an 100% umgesetzt wurden. Warum? Gesetzte und Vorschriften ändern sich, neue Technologien und Produkte werden verfügbar, Menschen haben neue Ideen und Meinungen, Dinge die auf dem Papier gut ausgesehen haben, stellen sich in der laufenden Software als nicht wirklich benutzerfreundlich dar oder man hat schlichtweg etwas falsch verstanden oder vergessen zu dokumentieren.
Die Standish Group hat in einer Studie herausgefunden, dass 45% der Funktionen einer Software nie benutzt werden! 20% werden sehr selten und 16% manchmal benutzt. Nur 20% der Funktionen einer Software werden laut dieser Studie immer oder oft genutzt. Das Ergebnis von Wasserfallprojekten und klassischen Festpreisen.
Habe beispielsweise in einem Projekt mitgearbeitet in dem wir in die Ergebnisliste einer Personensuche eine Sortierung nach Hausnummern eingebaut haben. Fachlich brauchte das niemand, aber im Pflichtenheft war spezifiziert, dass die neue Anwendung auch „alle Funktionen der Altanwendung“ unterstützen sollten. Diese war eine Visual Basis Anwendung und hatte eine Komponente verwendet, in der man eine Tabelle nach allen Spalten sortieren konnte. In unserer neuen Webanwendung hat die Sortierung aber Aufwand gekostet – wir haben trotzdem alle Spalten sortierbar gemacht…
Wenn man also davon überzeugt ist, dass man eine Software nicht zu 100% spezifizieren kann und man auch nicht vorab sagen kann, welche Funktionen man wirklich benötigt – ist dann der klassische Ansatz mit einem festen Umfang sinnvoll? Aus meiner Sicht nicht, weshalb wir auch den agilen Ansatz bevorzugen.
Der agile Festpreis
Es gibt sicherlich viele Ansätze und Varianten einen agilen Festpreis zu vereinbaren. Wir setzen auf einen Ansatz, den ich hier kurz beschreiben werde:
- Wir erstellen gemeinsam mit dem Kunden ein Backlog oder nutzen ein vorhandenes Backlog des Kunden. (das kann auch ein klassisches Pflichentheft sein, das bereits erstellt wurde)
- Wir schätzen die relative Größe der Funktionen auf Basis von Story Points, so dass wir am Ende eine Größe für die Storypoints des gesamten Projekts haben. Das Schätzen erfolgt am Besten mit Affinity Estimating weil es am schnellsten und effektivsten ist – ggf. kann aber auch Planning Poker verwendet werden. Das Einbinden des Kunden bei dieser initialen Schätzung hat sich bewährt, weil dies auf beiden Seiten für ein besseres Verständnis der Funktionen sorgt und viele Missverständnisse schon früh ausgeräumt werden können.
- Wir stimmen mit dem Kunden eine Definition of Done ab, die insbesondere auch Qualitätskriterien definiert und festlegt, ob die Anwendung beispielsweise von uns mit automatisierten Fachtests gesichert werden soll.
- Wir brechen unterschiedliche Stories exemplarisch auf Tasks runter und entwickeln Design Ideen für die Umsetzung. Auf Basis der Definition of Done erstellen wir eine Expertenschätzung für die Tasks und erhalten so eine Aufwand für die Stories in Personentagen. Wir mitteln dann den Aufwand auf Basis der Schätzungen für unterschiedlichen Stories und erhalten so einen Umrechnungsfaktor von Story Points auf Personentage. Am Besten validiert man diesen Wert noch einmal, in dem man ein anderes Team noch einmal diesen Umrechnungsfaktor bestimmen lässt – ggf. auch mit anderen Stories.
- Auf Basis der initialen Schätzung des Backlogs in Storypoints und des Umrechnungsfaktors wird der Aufwand für das initiale Backlog ermittelt.
- Der Aufwand multipliziert mit dem durchschnittlichen Tagessatz des Umsetzungsteams ergibt den Festpreis.
- Dieser Festpreis gilt jetzt aber nicht für den Umfang des initialen Backlogs, sonder für die Anzahl der initial berechneten Story Points. D.h. der Kunden kann den initialen Backlog damit umsetzen, muss es aber nicht. Er kann auch jederzeit Stories austauschen, neue hinzufügen und andere streichen – solange er den Gesamtumfang der Storypoints nicht überschreitet.
Es gibt natürlich noch Varianten zu diesem Vorgehen. Beispielsweise kann man den Aufwand für Storypoints auch durch ein paar wenige Sprints auf Basis von Zeit und Material ermitteln. So kann man den Umrechnungsfaktor sehr präzise empirisch bestimmen und hat auf beiden Seiten höhere Planungssicherheit. I.d.R. arbeite Dienstleister ohne diese Sicherheit mit einem „Risikoaufschlag“ bei der initialen Schätzung, um das Risiko von Mehraufwänden im Festpreis zu berücksichtigen. 30% Aufschlag sind dafür ein realistischer Erfahrungswert.
Eine weiter Variante ist Money for nothing – change for free, die Jeff Sutherland vorgeschlagen hat. Bei dieser Variante kann der Kunde jederzeit sagen, dass er das Projekt beendet, weil die gelieferte Funktionalität ausreichend ist. Die Differenz des Aufwandes wird geteilt, d.h. der Dienstleister erhält die Hälfte des Geldes für den nicht geleisteten Aufwand und der Kunde spart die andere Hälfte ein.
Fazit
Agilität und Festpreis müssen demnach nicht im Widerspruch stehen. Ganz im Gegenteil führt die Aufnahme von Qualität, Geschäftswert und Kundenzufriedenheit zu einer Win-Win Situation, die bei einem klassischen Festpreis meistens nicht erreicht wird.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Mirko Novakovic
21.2.2014 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Mirko Novakovic
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.