Scrum ist ein (IT) Projektframework mit dem die Kunden und Dienstleister eng zusammen arbeiten können und so schnell und sicher die Software erstellen können, die die Kunden tatsächlich benötigen.
Häufig stellt sich die Frage ob Scrum und Projekte, die zu einem fixen Betrag (Festpreis) umgesetzt werden sollen, zusammenpasst. Ich hatte das Vergnügen einige Projekte mit Scrum und im Festpreisumfeld durchführen zu dürfen. Dabei hatte ich Projekte, bei denen sich Festpreis und Scrum gut vereinbaren ließen. Leider hatte ich auch Projekte bei denen Scrum und Festpreis zu massiven Mehraufwänden und Verlust von Kundenvertrauen führte.
Hier habe ich eine Zusammenfassung erstellt, die das Thema etwas beleuchten soll.
Einige Eigenschaften von Festpreisprojekten
- Festpreisprojekte geben dem Kunden die Sicherheit, dass die Kosten (zuerst) nicht explodieren können. Das Risiko wird auf den Dienstleister übertragen. Diese Tatsache gibt dem Kunden finanzielle Planungssicherheit
- Ein Festpreisprojekt bedingt, dass die Anforderungen zu Beginn der Arbeiten klar definiert sind und von den Partnern verstanden worden sind. Ansonsten ist ein Festpreisprojekt mindestens für den Dienstleister ein sehr hohes Risiko und kann schnell zu einer Existenzkrise des Dienstleisters führen
- Durch die Tatsache, dass das finanzielle Risiko auf den Dienstleister übertragen wurde, werden Festpreisprojekte oft mit einem höheren Risikozuschlag angeboten um Unvorhergesehenes abzusichern
- Festpreisprojekte sollten nur dann durchgeführt werden, wenn die Technologie, die Geschäftsprozesse und das Umfeld für alle Beteiligten klar ist. Ansonsten können die Projektrisiken nicht sinnvoll abgeschätzt werden
- Der Wunsch des Kunden nach Planungssicherheit führt zu Verträgen bei denen am Ende beide Partner verlieren. Zwar muss die Funktionalität für den definierten Preis abgeliefert werden doch die Auslegung was die Funktionalität bedeutet wird im schlechtesten Fall vor Gericht geklärt. Dann haben auf alle Fälle beide Partner verloren.
Warum passt Scrum eigentlich nicht zum Festpreis?
Charakteristisch für den Einsatz von Scrum ist, dass die Softwarelösung in Iterationen gemeinsam mit dem Kunden erarbeitet wird.
Da zu Beginn der meisten Projekte nicht 100% klar ist, was eigentlich erstellt werden muss, werden während des Projektverlaufes Änderungen erfolgen. Hier bietet Scrum die Möglichkeit schnell auf Änderungen zu reagieren.
Im Fall eines Festpreisprojektes wird jedoch zuerst festgelegt was erstellt werden muss und genau diese Definition wird abgearbeitet. Auf Änderungen kann man im Prinzip nur durch Nachverhandlung oder den Aufbau neuer Projekte reagieren. Man hat sich gemeinsam auf einen Funktionsumfang geeinigt und muss diesen vertraglich einhalten.
Wo hat Scrum und Festpreis funktioniert?
Bei der Erstellung einer großen Web-Applikation konnte Scrum als Projektframework und ein Festpreis für den Kunden gut eingesetzt werden. Die wichtigsten Eckpunkte waren:
- Die Anforderungen waren zu mehr als 80% ausgearbeitet gewesen
- Die wichtigsten Architekturentscheide, Frameworkdefinitionen und Businessprozesse waren bekannt
- Alle Anforderungen waren klar (in Use Cases) beschrieben und konnten einzeln geschätzt werden. Dies konnte erreicht werden, da ein Anforderungsprojekt vorgeschalten wurde in dem die wichtigsten Eckpunkte bereits festgelegt waren.
- Das eingesetzte Entwickler Team beherrschte die komplette Umgebung und hatte vorher schon in dem Kundenumfeld gearbeitet
- Zwischen Team und Kunde wurden von Beginn an saubere Schnittstellen (technischer Product Owner und Bussines Product Owner) festgelegt
Der technische Product Owner war ein Requirement Engineer des Kunden. Diese Person hatte enge Verbindungen zu den Architekten, der internen Entwicklung und dem Betrieb.
Der Business Product Owner war eine Person aus dem Fachbereich. Er vertrat die Anforderungen der Systemnutzer.
Beide Product Owner definiterten gemeinsam die Priorisierung der Umsetzung. Der Gesamtprojektleiter war hier mit anwesend und konnte seine Punkte mit aufbringen. Der Scrum Master moderierte diese Sitzungen. Der Business Product Owner wurde als "Master" Product Owner definiert. Falls es zu einem Konflikt bei der Priorisierung des Product Backlogs gekommen ist, hat er die Entscheidung gefällt was als nächstes durchgeführt werden sollte. - Die Aufgaben des Projektleiters wurde in diesem Teil der Entwicklung auf die Product Owner, das Team und den Scrum Master aufgeteilt. Im Gesamtprojekt wurde ein Wasserfall-Modell eingesetzt. Der Projektleiter definierte die groben Schritte der Entwicklung, jede Iteration erhielt einen sinnvollen Namen der auch im Projektplan dargestellt wurde. Beispiele: PoC, Setup Identity Management, Setup Workflow Management...
Es wurden im Gesamtprojektplan die Use Cases eingetragen und pro Iteration wurden die tatsächlich realisierten Use Cases festgelegt. So entstand am Anfang Projektplan-Änderung von ca. 40%. Nach drei Iterationen waren es unter 10% und somit überschaubar. - Eine enge Zusammenarbeit zwischen dem Kunden und dem Dienstleister wurde von Beginn an angestrebt. Bei Fragen und Änderungen wurde gezielt über Lösungen gesprochen.
- Beide Parteien sahen den Festpreis nur als eine Fixierung der Projektvariablen (Preis, Qualität, Funktion, Zeit, Team) an. Weiter wurde auf die wichtigsten Geschäftsprozesse Wert gelegt und damit der Festpreis definiert
Es wurden also eine sehr enge Zusammenarbeit festgelegt. Während des Projektverlaufes kam es zu Änderungen. Dabei wurde wie folgt vorgegangen:
- Funktionen, die nicht mehr benötigt wurden, wurden durch neu definierte Funktionen die gleich viel Aufwand benötigten abgelöst
- Einzelne Themenbereiche, die zuvor nicht überschaut werden konnten, wurden gemeinsam verfeinert. Wir konnten erreichen, dass sowohl der Kunde als auch der Dienstleister auf Änderungen eingingen. Wir betrachteten dabei immer den zuerst definierten Funktionsumfang und änderten nur die Themen ab die sich mit dem Vertrag vereinbaren ließen.
Für beide Parteien war klar, dass der Funktionsumfang und der Preis stets gleichbleibend sein musste.
Ein Geschäftsprozess war falsch definiert gewesen. Dies erkannten wir nach einigen Iterationen und korrigierten dies sehr schnell. So konnten wir erreichen, dass der Kunde die Abläufe erhält die er wirklich benötigt. Für die Entwicklung war es wenig Mehraufwand. Dafür wurde ein technischer Aspekt, der deutlich mehr Mehraufwand für die Entwicklung bedeutet hätte, durch eine einfachere Lösung ersetzt. So konnten wir erreichen, dass am Ende die Funktionalität wie vereinbart erstellt werden konnte, die Schwachstellen jedoch korrigiert werden konnten.
Möglich war dies nur deshalb, da Kunde und Dienstleister eng miteinander arbeiteten.
Wo hat Scrum und Festpreis nicht funktioniert?
Bei einem weiteren Projekt hat die Anwendung von Scrum zu massiven Mehraufwänden und Verlust des Kundenvertrauens geführt.
Die wichtigsten Eckpunkte waren:
- Die Anforderungen waren nur sehr schwammig beschrieben. Eine Vorstudie zur Stabilisierung der Anforderungen fand nicht statt.
- Der Kunde war bis zum Ende der Meinung dass bei Scrum jederzeit Änderungen eingebracht werden können. Dies ist bei einem Festpreisprojekt meiner Meinung nach nicht möglich.
- Die Zusammenarbeit mit dem Kunden war schlecht. Wenig Feedback, kaum Reviews. Der Kunde stellte sich auf den Standpunkt, dass mit dem Festpreis er keine eigenen Arbeiten absolvieren muss. Dies führte zu massiven Fehlern bei der Realisierung. Bei "normaler" Scrum-Vorgehensweise hätte dies ebenfalls zum Verlust führen müssen, doch das Thema Festpreis hat dem Kunden den Glauben gegeben nicht mitwirken zu müssen.
- Die Technologie war nicht stark bekannt
- Das Team hatte in dem Kundenumfeld zuvor nur wenige Arbeiten durchgeführt
Dieses Projekt wurde mit Changes überhäuft. Es wurde eine Lösung geliefert die stark nachbearbeit werden musste. Für den Kunden entstand eine deutlich längere Projektlaufzeit. Für den Dienstleister explodierten die Aufwände.
Was hätten wir besser machen können?
Der Kunde hätte deutlich mehr involviert sein müssen. Festpreis entbindet nicht von der Mitarbeitspflicht. Weiter hätte dem Kunden von Anfang an mehr klar gemacht werden müssen, dass die Anforderungen bei einem Festpreisprojekt sehr genau bekannt sein müssen. Ansonsten muss ein Risikozuschlag von 100% oder mehr vereinbart werden. Das ist ebenfalls ziemlich unrealistisch.
Fazit
Wenn der Kunde mitarbeitet, und die Umgebung stabil und klar ist, kann Scrum für Festpreisprojekte eingesetzt werden. Es kann schnell auf Änderungen reagiert werden. Es muss dabei jedoch immer gegen den Vertrag geprüft werden ob die Änderungen in dem vereinbarten Rahmen liegen.
Wenn Anforderungen völlig unklar sind und der Kunde nicht mitwirken will, geht das Festpreisprojekt mit Scrum genauso schief wie mit allen anderen Vorgehensmodellen. Die Probleme liegen vor allem an der Tatsache, dass Festpreis dem Kunden das Gefühl gibt, alle Risiken abgewälzt zu haben.
10 Comments
Rainer Eschen
Könntest Du noch mal erläutern, was ein Technischer Product Owner ist und wie er in Eurem Fall mit dem Business Product Owner zusammengearbeitet hat? Wie war die Zusammenarbeit der beiden mit dem Projektleiter?
Roland Baldenhofer
Hallo Rainer,
ich habe die beiden Rollen (Technischer Product Owner und Busines Product Owner) sowie die Zusammenarbeit mit dem Projektleiter im Text kurz erläutert.
Janko Böhm
Mir hat hier ein Link von Roland Baldenhofer geholfen der auf eine Präsentation von J. Sutherland verwiesen hat wo die folgenden zwei Konzepte vorgestellt wurden:
Danijela Weißgraeber
Scrum und Festpreis funktioniert genau dann, wenn die Abwandlung der Funktionalitäten nur geringfügig sind. Und dem Kunden muss klar sein, das wenn innerhalb des Festpreisprojektes Funktionen oder Module stark verändert werden, so dass es zu Mehraufwand kommt, diese Aufwände in Form von Change Management als Extra-Aufträge verbucht und abgerechnet werden. Daher ist eine starke Mitarbeit gerade auch bei Festpreisprojekten essentiell.
Paul Allmer
Es ist eine alte Weisheit in einem Festpreisprojekt. Je geringer die Anforderungen/Use Cases beschrieben sind, umso höher das Risiko für beide Seiten. Hat sich auch mit Scrum nicht geändert
Ich finde Deine Aufstellungen wann welche Methode funktioniert hat sehr gut. Das kann man gut nutzen, wenn man beim Kunden sitzt und diese Diskussion aufkommt.
Wolfram Müller
Ich hab noch eine Variante, die ich in meinen frühen Jahren als Freelancer eingesetzt habe. Es ähnelt etwas dem Tit-for-Tat-Prinzip.
Die eigentliche Sorge des Auftraggebers ist doch, dass die Kosten weglaufen (oder Qualität oder Zeit). Das Problem des Auftragnehmers ist, dass er den Aufwand nicht gut abschätzen kann. Gewürzt, damit, dass noch gar kein Vertrauensverhältnis besteht.
Was ich immer gemacht hab waren zwei Verträge. Einen "kleinen" wenige Tage mit dem Ziel a) Erfahrung sammeln auf meiner Seite b) prototypische was zeigen und c) gemeinsam Auftrag klären und Vertrauen aufbauen. Das Ergebnis war dann ein zweiter Vertrag für den Rest des Projektes. Wie im Artikel oben genannt muss das nicht perfekt sein 80% waren immer ausreichend. Der Effekt ist dass der Risikozuschlag runter geht und die Sicherheit, dass beide Seiten zufrieden werden deutlich steigt. Das ist auch mit Großkonzernen leicht zu verhandeln.
Das geht auch mit agilen Projekten - zuerst ein zwei Sprints zur Klärung und zum Aufbau des Vertrauens und dann im zweiten Teil zum Vollprojekt übergehen. Hier möchte ich einfach auch nochmal auf die Idee des Reliable Scrum hinweisen. Das kann hier ideal zum Einsatz kommen um genau die Streuungen und die Risiken transparent zu machen und kooperative mit dem Auftraggeber festzulegen.
Bernhard Schloß
Hallo Wolfram,
das funktioniert aber nur, wenn du eine relativ starke Verhandlungsposition hast, ansonsten wird der Kunde versuchen einfach den ersten Vertrag zu verlängern.
Gruß
Bernhard
Jens Hoffmann
Aus meiner Sicht führt diese Diskussion und ihre Argumente in die falsche Richtung. Was hier unter Festpreis-Projekt verstanden wird, ist ein Projekt, dass einen festen Projektumfang mit einem vorher festgesetzten und unveränderlichen Preis verbindet.
Das hier fleissig kommentiert wird, so etwas würde nur gehen, wenn denn vorher alle Anforderungen bekannt seien und hinreichend genau festgeschrieben seien, ist ja schon fast eine Tautologie. Wäre das der Fall und wäre das tatsächlich möglich, dann bräuchte man kein agiles Vorgehen wie SCRUM. Denn wozu brauche ich ein Vorgehen für mein statisches Vorhaben, welches dafür designed ist mit dynamischen und häufigen Anforderungswechseln umzugehen und dabei sicherzustellen, dass der maximale Kundennutzen bei festem Budget erreicht wird.
Wenn aber der Kunde oder Nutzer nicht in der Lage ist exakt und verbindlich zu definieren, welche Anforderungen er umgesetzt haben möchte, dann ist weder mit einem klassischen Projektmanagement, noch mit einem agilen Vorgehen ein verbindlicher Preis für einen festen Scope (welcher überhaupt, wenn er doch gar nicht beschrieben werden konnte?) umsetzbar. Es sei denn, der Festpreis hatte eine Menge Luft nach oben enthalten, oder der Auftragnehmer hätte eine große Freude an finanziellen Einbußen.
Die Darstellung des Erfahrungsberichtes zeigt aus meiner Sicht, dass das handelnde Team und sein Management nicht wusste, was es tat:
Diesen insgesamt mangelhaften Projektansatz dem Vorgehen SCRUM in die Schuhe zu schieben, halte ich für unzulässig. Wenn man agile Vorgehensweisen "nur" als eine andere Folge von Prozessschritten begreift und daneben alle Grundlagen ordentlicher Risikoabschätzung und Vertragsgestaltung sowie die Prinzipien agilen Managements weder beherzigt, noch seinen Kunden ausreichend informiert, dann kann das Ergebnis nur so katastrophal werden, wie es oben beschrieben wurde.
Aber vielen Dank an den Autor der Fallstudie, dass er uns dieses fabelhaft Lernmaterial so offen zur Verfügung gestellt hat. Denn insbesondere aus derartigen Fehlkonstruktionen, kann man am meisten für die Zukunft lernen.
Steffen Thols
Und hier noch meine 2 Cent:
Der wichtigste Faktor zur erfolgreichen Abwicklung eines Projekts -ob nun agil durchgeführt oder nicht- liegt in dem gegenseitigen Vertrauen der Vertragspartner (Auftraggeber und Auftragnehmer).
Für Leseratten: Siehe dazu auch das Kapitel 7 des hervorragenden Buches der Poppendiecks „Lean Software Development: An Agile Toolkit“
Dieses meist leider fehlende Vertrauen führt ja eben dazu, dass der AG versucht, sein Risiko auf den AN mittels Werkvertrag zum Festpreis abzuwälzen. Der AN reagiert wiederum mit einem rigiden Claim Management. (Mir wurde mal gesagt, dass manche Baufirmen die (öffentlichen) Ausschreibungen von Architekten auf Fehler analysieren um dann ein vermeintlich wirtschaftlich günstiges Angebot abzugeben, welches dann durch die Nachträge für den AN sehr lukrativ wird. Ich hoffe, so etwas gibt es in der Software-Branche nicht … :-))
Und dabei hat man in der Baubranche eine mehr als tausendjährige Erfahrung und kann sich unter einem Haus zumindest etwas vorstellen. Im Gegensatz zur Softwareentwicklung, die gerade einmal knapp 70 Jahre auf dem Buckel hat und vom Anforderer ein nicht geringes Maß an Abstraktionsvermögen erfordert.
Agile Vorgehensweisen wie z.B. Scrum fordern nun die Mitarbeit des AG strikt ein um dadurch ein gemeinsames Verständnis und offene Kommunikation über das Vorhaben zu erzielen. Falls dann beispielsweise wie in dem Artikel beschrieben mit der Technik Neuland betreten wurde, die zuliefernden Fachbereiche nicht ausreichend mitmachen oder andere Schwierigkeiten auftreten; die Entscheider des AG sind sich immer der aktuellen Lage des Projektes bewusst und können (sollten) schnellstmöglich Gegensteuern.
Dies gelingt natürlich nur, wenn ein Schwenk in den Köpfen dahingehend entsteht, dass alle – Fachabteilungen, Dev, Ops , externe Dienstleister, etc. – in einem Boot sitzen, wenn es um den Erfolg oder eben Misserfolg eines Projektes geht. Das beliebte „Fingerpointing“ funktioniert in agilen Projekten halt nicht mehr, wenn jeder zu jedem Zeitpunkt über den Status und aktuelle Probleme des Projektes informiert war.
Ach ja, natürlich sollte ein grundsätzliches Hintergundwissen um agile Vorgehensweisen bei allen Beteiligten (inkl. Management) vorhanden sein, denn sonst missbraucht eine undisziplinierte Fachseite ein agiles Vorgehensmodell als Blankovollmacht für ein unreflektiertes Anforderungschaos!
Janko Böhm
Von so einem Vorgehen im Bau weiß ich auch. Der Architekt erstellt in einer separaten Beauftragung einen Plan, lässt den vom Auftraggeber freigeben und holt eine Baufreigabe ein - dann geht es an die Umsetzung und die Vertragspartner erhalten den genauen Plan mit Größen und Mengen incl. einer Beschreibung des "Wie" aufgeteilt nach den Losen und Gewerk.
In der SW-Entwicklung hat die Fachabteilung (AG) eine tolle Idee, der Plan und die Anforderungsbeschreibung ist eher unspannend und man nimmt einfach die Spec von vor 4 Jahren incl. der Dokumentation des letzten Softwarepartners die je nach Komponente zwischen 4 Jahre alt und noch nicht umgesetztem Wunschdenken rangiert und vergibt die gesamte Aufgabe: Planung UND Umsetzung in einem Rutsch. Die Freigabe durch das Bauamt macht in dem Falle die zentrale Architektur durch Abnicken - denn wenn sie es nicht tut baut der Fachbereich Druck auf und es geht dann doch ohne die notwendige Korrektur der nicht passenden Komponenten zur Infrastruktur.
Von dem Missbrauch der "ProductOwner" das agile Vorgehen als Freifahrtsschein zu nutzen ein Projekt ohne konkrete Vorstellungen und Scope anzugehen habe ich auch schon gehört. Es soll sogar Manager des Fachbereiches geben die das nicht "unter vorgehaltener Hand" machen sondern damit die Projektkosten offiziell herunterrechnen weil man das ganze Drum-herum und speziell das überfüssige Anforderungsmanagement nicht braucht. Echt super ist es auch, dass man in einem SCRUM Projekt ja gar keinen Projektmanager braucht - nochmal unnötige Kosten gespart - wow.
Also, Herr Thols ich stimme Ihnen absolut zu :
Es sollte ein "grundsätzliches Hintergundwissen um agile Vorgehensweisen bei allen Beteiligten (inkl. Management) vorhanden" sein.
** eine Story die das Leben schrieb ** (das Kapitel habe ich vergessen)