Agiler Festpreis

6 Kommentare

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:

  1. 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)
  2. 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.
  3. 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.
  4. 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.
  5. Auf Basis der initialen Schätzung des Backlogs in Storypoints und des Umrechnungsfaktors wird der Aufwand für das initiale Backlog ermittelt.
  6. Der Aufwand multipliziert mit dem durchschnittlichen Tagessatz des Umsetzungsteams ergibt den Festpreis.
  7. 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.

Als Mitbegründer und Advisor der codecentric AG berät Mirko bei der strategischen Ausrichtung des Unternehmens. Er ist Geschäftsführer und Mitgründer der Startups CenterDevice und Instana – beides disruptive Geschäftsmodelle auf Basis von Big-Data- und Cloud-Technologien.

Seine Interessen liegen im Bereich der Veränderung von Geschäftsmodellen durch moderne Technologien und Software, also der zunehmenden Digitalisierung der Welt und den daraus resultierenden Veränderungen und Potential für Unternehmen.
Im Privatleben widmet er sich am liebsten seiner Familie, zum sportlichen Ausgleich fährt er Mountainbike.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Artikel von Mirko Novakovic

Konferenzen

APM Mythen Jäger entlarvt

Debunking the APM myth busters

Weitere Inhalte zu Agile Management

Agile Management

Planlos agil

Agile Management

legacy.org => agile.org (Teil 3)

Kommentare

  • Thomas Scherm

    17. August 2011 von Thomas Scherm

    klasse Artikel!

    Für die Abschätzung eines größeren Backlogs habe ich gute Erfahrungen mit folgendem alternativen Schätzvorgehen gemacht:

    – Schätzen des Backlogs in T-Shirtgrössen (XS, S, M, L, XL, XXL) durch das Team

    – Pro T-Shirt Größe werden 5 User Stories durch Vorting gefiltet, die das Team für representativ und gut verstanden hält.

    – Jedes Team Mitglied führt eine stille Expertenschätzung in Personentagen unter Zeitdruck (wichtig wg. Intuition) durch.

    – Die zwei User Stories pro T-Shirtgröße mit den größten Abweichungen werden entfernt.

    – Bildung des Mittelwerts –> Personentage pro T-Shirtgröße –> Hochrechnung des Backlogs.

    Ich habe die Erfahrung gemacht, dass diese Schätzung bei größeren Backcklogs sehr stabil ist. Abweichungen zum Ist sind in der Regel in der Größenordnung von ca. 5 – 10%.

    Da man dabei auf das Gesetz der großen Zahlen und Mittelwertseffekte setzt, muss die Anzahl der User Stories groß genug sein.

  • Steffen Thols

    19. August 2011 von Steffen Thols

    Hallo Hr. Novakovic,
     
    sehr guter und interessanter Artikel!
     
    Meine Hoffnung ist, dass sich die Erkenntnis immer mehr durchsetzt, dass Werkverträge zu Festpreisen in der IT i.d.R. Probleme für alle Beteiligten mit sich bringen. Auftraggeber bekommen nicht, was sie wirklich benötigen und Auftragnehmer müssen das Risiko einer ungenauen Spezifikation und/oder technische Risiken tragen. Das leidige Thema Change Requests trägt auch nicht gerade zur Verbesserung des Klimas zwischen AG und AN bei. Hier können wir aus der Baubranche mit ihrer HOAI „lernen“, denn es kommt nicht von ungefähr, dass Bauvorhaben so gut wie immer teurer werden, als geplant und meist auch länger dauern. (V.a. bei öffentlichen Ausschreibungen, denn dort muss immer das vermeintlich günstigste Angebot angenommen werden. Das Geld holen sich die AN dann durch die sog. Nachträge)
     
    Zur Lösung dieses Dilemmas können agile Methoden das probate Mittel sein. Um aber dahin zu kommen bedarf es neben der Überzeugungsarbeit beim Management über die Vorteile einer agilen Vorgehensweise v.a. der Mitnahme der involvierten Fachbereiche des AG. Das bisherige Prinzip des „Fire and Forget“ (=ich gebe mein Lastenheft ab und erwarte in ein paar Monaten die fertige Software zum Test ohne weitere Arbeit bis dahin) funktioniert dabei nicht mehr.
     
    Hier müssen natürlich die Dienstleister ihre Kunden auf dem Weg zu einem agilen Projektvorgehen begleiten und unterstützen. Neben den Änderungen in den SW-Entwicklungspraktiken ändern sich auch die Anforderungen an den auftraggebenden Part in den Fachbereichen massiv.
     
    Einer der wichtigsten Punkte dabei ist m.E., dass der Kunde die „Ungewissheit“, dass im Vorfeld des Vorhabens die Anwendung eben nicht komplett en detail spezifiziert ist als Chance begreift, im laufenden Projekt noch wichtige Änderungen vornehmen zu können, um auf Marktanforderungen oder andere Gegebenheiten schnell reagieren zu können, ohne einen leidigen CR-Prozess (s.o.) einleiten zu müssen.
     
    Grundlage dafür ist natürlich eine Vertrauensbasis zwischen AG und AN, die hoffentlich nicht bereits durch fehlgeschlagene Werkverträge zu Festpreisen zerstört wurde…

    • tural

      „Einer der wichtigsten Punkte dabei ist m.E., dass der Kunde die „Ungewissheit“, dass im Vorfeld des Vorhabens die Anwendung eben nicht komplett en detail spezifiziert ist als Chance begreift, im laufenden Projekt noch wichtige Änderungen vornehmen zu können, um auf Marktanforderungen oder andere Gegebenheiten schnell reagieren zu können, ohne einen leidigen CR-Prozess (s.o.) einleiten zu müssen.“

      Diesem Satz kann ich nur zustimmen. In diesem Zusammenhang stellt sich die Rolle „Product Owner“ in den Mittelpunkt von agilen Vorhaben.

  • Heiko Nardmann

    Auch wenn der Artikel gut geschrieben ist, so frage ich mich, warum Bekanntes (zu diesem Pseudo-Widerspruch) so oft wiederholt wird. Solche Artikel habe ich schon mehrfach im Web gelesen; jedoch sind die dargestellten Aspekte schon während meiner CSM-Schulung vom Trainer sowie in den Büchern von Mike Cohn und auch von Bernd Oestereich angesprochen worden.

    Sollte man da nicht annehmen (oder hoffen), dass sich zumindest ScrumMaster kontinuierlich mit frischem Wissen versorgen? Leider scheint dies nicht der Fall zu sein.

    Aber das mit der fehlenden Weiterbildung scheint ja ein allgemeines Problem der IT-Industrie zu sein – angesichts der Tatsache, dass die XP-Ideen schon 1990 in Büchern gegossen waren und teilweise selbst heute noch nicht überall angekommen sind – zumindest habe ich dies so in meinem letzten Unternehmen erlebt und teilweise auch während der CSM-Schulung durch die Aussagen am Rande der Veranstaltung erfahren.

    Dem von Steffen angesprochenem Aspekt Vertrauensbasis kann man nicht genug Beachtung schenken, da ein „verbrannter“ Kunde (durch überzogene Projekte zusammen mit zu wenig Kommunikation) natürlich kaum zurück kommt, auch wenn sich vielleicht einiges zum Guten geändert hat. Wenn man einmal beim Kunden unten durch ist, dann kostet es viel Arbeit, dieses Gefühl im Unterbewusstsein des Kunden wieder aufzuheben – wenn dies überhaupt noch möglich ist.

  • Mirko Novakovic

    23. August 2011 von Mirko Novakovic

    Hallo Heiko,

    mit meinem Blog Eintrag möchte ich ein wenig helfen den Schritt von „Wissen“ zu „Können“ mit Agilität zu meistern. Deshalb beschreibe ich, wie wir Dinge erfolgreich in der Praxis machen und zeige zudem die Hintergründe dazu auf – natürlich nicht immer alles neu, aber mir geht es auch eher um den „Best Practice“ Gedanken.

    Eines der Probleme ist doch, dass Agilität nicht einfach ist und man mit Wissen nicht weit kommt. Du fragst, warum XP nicht schon bei jedem angekommen ist? Weil es schwierig zu erlernen ist und deshalb auch nicht für jedes Team geeignet ist. Fast zu jeder Praktik in XP kann man mindestens ein eigenes Buch schreiben oder ganze Buchserien – beispielsweise zu TDD oder Refactoring. Und selbst wenn man die Bücher dann gelesen hat, wird man i.d.R. Jahre der Praxis benötigen, um die Techniken wirklich zu beherrschen. Deshalb halte ich es für sinnvoll Best Practices weiter zu geben.

    Dies gilt dann auch für Scrum. Auch hier suggeriert ein 2-Tages Training, das man danach Scrum „Master“ ist. Gutes Marketing, aber eigentlich auch eine Gefahr. Habe das Training aus Interesse drei mal gemacht: Bei den beiden Scrum-Vätern Jeff Sutherland und Ken Schwaber und bei Boris Gloger, dem ersten deutschsprachigen Scrum Trainer. Jeder Kurs war eine eigene „Interpretation“ von Scrum – d.h. man konnte in jedem Kurs etwas Neues lernen – nur die Basiselemente waren gleich. Es gibt beispielsweise viele Leute, die denken, dass Planning Poker oder User Stories zu Scrum gehören.

    Scrum ist in der Umsetzung deshalb auch (sehr) schwierig, weil man viele „dunkle Flecken“ selber füllen muss (beispielsweise auch das Thema Festpreis und Vertraggestatlung mit Scrum) und deshalb denke ich, dass jeder Blog Eintrag ein Mehrwert ist – insbesondere weil ich persönlich sehr häufig zum Thema „Scrum und Festpreis – geht das überhaupt?“ angesprochen werde.

    Teilweise sind es noch viel einfachere Dinge, die zu Diskussionen führen: „Muss der ScrumMaster am Daily Scrum teilnehmen?“

    Eine einfache Frage, mit einer eindeutigen Antwort, aber mind. 50% auch zertifizierter ScrumMaster beantworten die Frage falsch und noch viel mehr können die Antwort nicht erklären. Nicht weil sie sich nicht weiter bilden oder kein neues Wissen aneignen, sondern weil in der Regeln die Erfahrung fehlt und damit der Nutzen nicht selber erlernt wurde. Man könnte also alleine über diese einfache Frage einen Blog Eintrag schreiben, würde nichts Neues erzählen, aber sicherlich zum Verständnis beitragen.

    Mirko

    • tural

      „Es gibt beispielsweise viele Leute, die denken, dass Planning Poker oder User Stories zu Scrum gehören.“

      In der Tat 😉

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.