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.
Attachments:
Comments:
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?
Posted by rainwebs at 30. Apr 2012 18:56
|
||
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.
Posted by roland at 01. Mai 2012 08:50
|
||
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: Vertragsklausel –„Change for Free“ (J. Sutherland https://docs.google.com/viewer?url=http%3A%2F%2Fjeffsutherland.com%2FAgile2008MoneyforNothing.pdf) S. 31
Vertragsklausel – „Money for Nothing“ (J. Sutherland https://docs.google.com/viewer?url=http%3A%2F%2Fjeffsutherland.com%2FAgile2008MoneyforNothing.pdf) S. 33
Posted by janko böhm at 13. Jun 2012 17:43
|
||
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.
Posted by spacedani at 14. Jun 2012 14:21
|
||
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.
Posted by allmerpa at 18. Jun 2012 15:16
|
||
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.
Posted by wmueller at 18. Jun 2012 22:30
|
||
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
Posted by bschloss at 19. Jun 2012 22:08
|
||
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.
Posted by jhoffmann at 19. Jun 2012 23:43
|
||
Posted by steffen.thols at 20. Jun 2012 15:39
|
||
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)
Posted by janko böhm at 20. Jun 2012 16:36
|