Wie passen Agilität und Festpreis zusammen?

Geschrieben von Peter Beck am 11.11.2013

“Kunden wollen Sicherheit über einen Festpreis. Häufig wird deshalb bereits im Voraus ein Produkt Backlog angefertigt und die Storys geschätzt. Doch bin ich dann wirklich noch agil? Die geschätzten Storys und der daraus festgelegte Preis ergeben, wie viele Personentage ich maximal brauchen darf und daraus auch, wie viele Storys pro Sprint abgearbeitet werden müssen.”

Die agilen Werte und die Scrum Prinzipien müssen auch bei der Vertragsvereinbarung zwischen Kunde und Lieferant berücksichtigst werden. Darauf aufbauend muss man verstehen, was Scrum als Rahmenwerk schon mitbringt, um die Zusammenarbeit zu regeln und um schließlich zu entscheiden, welche Praktiken für den konkreten Fall eingesetzt werden. Um die Frage möglichst umfassend zu beantworten, gehe ich auf diese 3 Ebenen nacheinander ein.

(1) Zur den Werten und Prinzipien: Wie Sie in Ihrer Frage schon feststellen, möchte der Kunde mehr Sicherheit erlangen. Er glaubt dies durch einen Festpreis mit einem festen, funktionalen Umfang erreichen zu können, was ja auch sehr naheliegend ist. Denn so liegt das Risiko scheinbar beim Dienstleiter. Scheinbar - denn das Risiko ergibt sich ja nicht nur aus der technischen Komplexität, sondern auch aus der Komplexität, welche das Geschäftsmodel des Kunden mitbringt. Einen fixen, funktionalen Umfang am Anfang festzulegen ist daher nicht nur utopisch sonder aus Sicht des Kunden höchst risikoreich. Typischerweise rechne ich mit Varianz in der Schätzung zischen 25 und 100% für den funktionalen Umfang, bevor mit der Umsetzung gestartet wurde. Die gleiche Größenordnung kommt dann noch für die technische Umsetzung dazu. Nach 1/3 des Projektverlaufes liegt die Schätzgenauigkeit vielleicht schon zwischen 10% und 50% in beiden Bereichen. Fixpreis mit einem festen funktionalen Umfang gibt uns leider keine Möglichkeit dieses Wissen zum Wohle des Kunden und des Lieferanten auszunutzen. Sie als Dienstleister möchten aber auch Sicherheit. Am liebsten wäre Ihnen daher Time and Material. Aber wo bleibt da die Motivation für den Dienstleister das Beste zu geben, das Projekt nicht auf Ewigkeiten auszudehnen und wie die Made im Speck zu leben? Jeder der traditionellen Ansätze geht immer zu Lasten eines der Partner. Meist wird versucht durch weitere Klauseln im Vertrag diese Unzulänglichkeiten abzufedern. Ein Klassiker sind Regelungen für Change Requests. Durch solche Klauseln hat der Kunde dann oft das Gefühl über den Tisch gezogen zu werden. Oder der Dienstleister hat das Gefühl immer mehr Liefern zu müssen, was nicht vereinbart war. Um es kurz zu sagen - das macht keinem Spaß und endet meistens mit Tränen. Das Agile Manifest proklamiert dazu eine Werteveränderung: Wir werten “Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung”. Agile fordert also das Vertrauen des Kunden, also sein Bedarf an Sicherheit, auf anderen Wegen zu befriedigen als über einen festen Umfang. Welche Werte dabei helfen sollen findet man vor allen in 2 der anderen Statements: * Wir werten “Funktionierende Software mehr als umfassende Dokumentation” * Wir werten “Reagieren auf Veränderung mehr als das Befolgen eines Plans”

Damit ein Vertragswerk Agile ist, muss es also die Werte widerspiegeln und so aufgesetzt sein, dass Lieferant und Dienstleister beide zu gleichen Teilen das Projektrisiko übernehmen. Nur so sind beide motiviert das Projekt zum Erfolg zu bringen. Ich vergleiche das gerne mit einer Wage. Ist diese nicht von Anfang an ausgeglichen und hat man nicht Vorkehrungen getroffen, dass die Wage durch Nachjustierung im Projekt ausgeglichen beleibt, wird das Projekt mit großer Sicherheit ein Desaster und mit noch größerer Sicherheit werden die Vertragspartner danach nicht mehr zusammenarbeiten.

(2) Was bietet uns Scrum dazu? Scrum implementiert dazu folgende Prinzipien, um die Agilen Werte umzusetzen: Überprüfen und Anpassen ist für den Kunden vor allem durch Review, Retrospektive, Backlog Refinement und Sprint Planning und die Möglichkeit das Product Backlog im Projekt zu verändern sichtbar. Transparenz für alle Beteiligten - also auch zum Kunden - zum Beispiel durch Frühe und regelmäßige Lieferungen, welche dem Kunden Sicherheit über den Fortschritt geben und sehr früh einen Wert schaffen. Und natürlich fundamentale Spielregeln in Zusammenarbeit zwischen den Rollen Kunde und Dienstleister. In der Scrum Sprache Product Owner und Entwicklungsteam genannt. Diese Regeln gehören in einen Agilen Vertrag. Und zwar nicht am Ende als Ergänzung zu einem Werksvertrag sondern zu Anfang, um die Grundlagen zu legen. Nun setzt Scrum als Rahmenwerk bewusst nur die Eckpfeiler der Zusammenarbeit. Das ist gut so, denn per Definition ist jedes Projekt ein einmaliges Vorhaben. Das bedeutet auch, dass jeder Vertrag zwischen Lieferant und Auftraggeber einmalig ist. 

(3) In der Praxis kann das zum Beispiel so ablaufen: Ein Unternehmen (gleich Kunde) möchte ein neues, innovatives IT-Produkt entwickeln und dazu einen oder mehrere Lieferanten beauftragen. Die Frage nach der Sicherheit ist natürlich die Kernfrage. Die Festpreisfalle ist unserem Kunden - Gott sei dank - schon durch die Erfahrung mit früheren Projekten bewusst und seine Kernfrage ist nun: Wie finden wir die richtigen Lieferanten? Natürlich zunächst einmal durch Interviews, Leistungsnachweise und Begutachtung von Referenzen. Aber reicht das aus, um das ganze Projektbudget auf eine Karte zu setzen? In unserm Bespiel entscheidet sich der Kunde erst einmal per Sprint zu beauftragen. Sozusagen Fixpreis für einen Sprint. Dadurch lernt der Kunde den Lieferanten besser kennen, sowie den eigenen Bedarf genauer zu definieren. Das Team des Lieferanten lernt dadurch schneller die technologische Komplexität einzuschätzen. Außerdem ist unser Lieferant in dem Beispiel erfahren mit Scrum und stellt dem Kunden ein Team zur Verfügung, das schon längere Zeit zusammenarbeitet. Ein beträchtlicher Risikofaktor fällt damit schon einmal weg. Das Risiko des Kunden liegt also zunächst bei max 1–3 Sprints relativ zu einem vermeintlichen Gesamtaufwand von vielleicht 9–18 Sprints bis zum ersten Release. Der Lieferant kann jederzeit den Auftrag verlieren. Ein Weiterverkauf des Teams an ein neues Projekt dauert vielleicht 2–4 Monate. Das Risiko auf den Personalkosten sitzen zu bleiben relativ zum möglichen Gesamtgewinn, welchen er mit dem Projekt erzielen kann, ist ähnlich hoch wie für den Kunden. Nach 2–3 Sprint ist die Schätzgenauigkeit und das Verständnis für den benötigten Umfang für ein erstes Release so gut, dass ein Umfang- bzw. Kostendach für alle Muss-, alle Soll- und 50% aller Kann-Features bei einer gut verstandenen Defintion of Done (also den nicht-funktionalen Anforderungen) für das Release definiert werden kann. Damit bleibt genug Spielraum im Soll- und Kann-Bereich, um im weiteren Projektverlauf funktional nachzubessern ohne den Gesamtaufwand zu erweitern. Gleichzeitig haben sich Kunde und Lieferanten Anreize im Vertrag definiert, um den gedeckelten Gesamtaufwand nicht vollständig auszunutzen, sondern schneller, wertoptimiert und mit möglichst minimalem Umfang zu releasen. Ein solches Model ist in der agilen Community auch als “Money for Nothing, Change for free” bekannt.

Abschließend kann man also sagen: Festpreis und Agile passen sehr gut zusammen. Festumfang und Agile widersprechen sich.

Yuliya Mijuk

Über den Autor

Peter Beck

Peter ist leidenschaftlicher Scrum Coach, Trainer (Certified Scrum Trainer, CST) und Moderator mit einem soliden Hintergrund im Engineering. Seit mehreren Jahren trainiert und coacht er eine große Bandbreite von Entwicklungsteams, Fachabteilungen, Projektleitern und Führungskräften in der Anwendung von Scrum, agilen Planungsmethoden und Softwareengineerings-Praktiken.
Peter hat die Österreichische Scrum Gruppe gegründet, an den Scrum Checklisten mitgewirkt, Publikationen auf InfoQ.com veröffentlicht. Er hält regelmäßig Vorträge auf agilen Konferenzen und Community Events.

  • Erfahrung mit Scrum seit 2004 als Teammitglied, ScrumMaster, Product Owner, Coach und Trainer.
  • Führen von international verteilten Scrum Teams als ScrumMaster
  • Mitgründer und Partner der DasScrumTeam AG
  • Besondere Interessen: Agile Unternehmen und Scrum beyond Software
Tags