Es gibt einen Grund, warum besonders Großkonzerne Scrum scheuen. Nicht, dass sie Scrum nicht einsetzen, aber oft mit nur wenig Überzeugung und noch häufiger eher als Getriebene aus einer Not heraus.
Der Vorwurf: Scrum Projekte sind schlecht planbar und schon gar nicht Festpreis-fähig.
Begründet wird das mit der Methodik selbst, in der funktionale Anforderungen vor Implementierungsstart als Stories oder Epics im Product-Backlog nur grob beschrieben sind und Überlegungen zur Architektur und Technologie oft noch gar nicht stattgefunden haben.
Somit ist die Methodik dem Management in großen Projekten, die zumeist mit festen Budgets ausgestattet (intern)- bzw. als Festpreis angeboten (extern) werden müssen, schwer zu verkaufen. Zu hoch scheinen die Risiken einer Fehlkalkulation.
Dennoch gibt es zunehmend mehr Projekte, die in klassischer Weise nicht mehr vorgeplant werden können, sei es, dass die Zeit fehlt, oder die Komplexität zu hoch ist inklusiver großer Vernetzung mit anderen Systemen und den daraus schwer einschätzbaren Abhängigkeiten.
Scheinbar ein Dilemma und Grund genug, hier einen Weg aufzuzeigen, wie Scrum – Projekte festpreisfähig gemacht werden können.
Ein Festpreisangebot für ein Software Entwicklungsprojekt abzugeben ist ohnehin eine große Herausforderung. Es erfordert eine genaue Kenntnis über die funktionalen Anforderungen des Kunden, die einzusetzenden Technologien, die betroffenen Schnittstellen, die geplante Architektur, die Skills der eigenen Mitarbeiter, die Möglichkeit paralleler Entwicklung etc.
Wie wir später noch sehen werden, haben deutlich über hundert Faktoren Einfluss auf die tatsächlich zu erbringenden Entwicklungsaufwände. Dies gilt für jedes Projekt egal welche Methodik zum Einsatz kommt.
Hinzu kommt das oben erwähnte Scrum Handicap der nur grob beschriebenen funktionalen Anforderungen zum Zeitpunkt der Projektplanung.
An dieser Stelle möchte ich noch gleich mit einem leider weit verbreiteten Missverständnis aufräumen, falls Sie sich auch gerade an dem Begriff „Projektplanung“ im Zusammenhang mit Scrum gestoßen haben.
Scrum ist eine Implementierungsmethodik, keine Projektmanagement Methodik, d.h. Scrum funktioniert innerhalb eines Projektes nicht anstelle des Projektes bzw. als Projekt selbst.
Das beantwortet dann auch die Frage, ob in Scrum noch Projektleiter benötigt werden und solche Dinge wie Projektpläne, Review Boards, jour fixe und vieles mehr. Ja, sie werden, allerdings müssen sie auf den Einsatz der gewählten agilen Implementierungsmethodik zugeschnitten werden. Das gilt sowohl für die Projektrollen, als auch für die Projektsteuerungsinstrumente.
Zum Festpreis in Drei Schritten
Zurück zum Festpreis Problem und zu einem Vorschlag, wie sie es lösen können, denn das ist durchaus möglich.
Um die Aufgabe zu bewältigen empfiehlt es sich, zunächst die Komplexität zu reduzieren und das gelingt uns durch die Einnahme einer Scrum-typischen Perspektive: Eine Software wird über ihre Featues beschrieben, nicht über ihre Technik, Architektur, Layer oder was auch immer.
Wir betrachten den Funktionsumfang getrennt von deren Implementierung und versuchen für beides jeweils ein Maß zu finden.
Kurz, um ein Festpreis für ein Softwareprojekt zu ermitteln benötigen wir in unserem Ansatz drei Informationen:
- Scope (Story Points, Functionpoints oder Agile Functionpoints)Sie benötigen ein Maß für den Scope, sprich die funktionale Größe der zu entwickelnden Software
- AufwandSie benötigen ein Maß für den Aufwand, den Sie betreiben müssen, um Funktionalität zu implementieren
- KostenIhre Kosten und Preise
Letzteres können wir in unserer Betrachtung vernachlässigen, denn Ihre Kosten pro „managed workplace“, sollten Ihnen bekannt sein. Falls nicht, hätten Sie ein grundsätzliches Problem und müssten betriebswirtschaftlich nochmal ganz von vorne anfangen.
Der erste Punkt repräsentiert die Scrum-typische feature-orientierte Sichtweise, während der zweite Punkt die oben bereits erwähnten über hundert Faktoren behandelt, die Einfluss auf den tatsächlichen Entwicklungsaufwand pro Funktionseinheit haben.
Einige davon sind die einzusetzenden Technologien, die grundsätzliche Architektur (z.B. Client Server oder SOA), die Skills der Entwickler, die Kommunikation mit Ihren Kunden, der Einsatz von Nearshoring oder Offshoring, die Art Ihrer Unternehmensorganisation (z.B. Matrixorganisation), Ihre CI-Strategie, die Anzahl und Verfügbarkeit von Testsystemen und Testdaten, die geplante Projektdauer, die Anzahl von Entwicklern, die Projektsprache und vieles mehr. Viele dieser Faktoren sind unternehmensspezifisch, andere (aber auch viele) sind projektspezifisch.
Schnell oder präzise: ‚Story Points‘ oder ‚Function Points‘
Der Funktionsumfang einer zu entwickelnden Software wird in Scrum üblicherweise in Form von Features beschrieben. Ein Feature beschreibt, was entwickelt werden soll, nicht wie es implementiert wird.
Natürlich werden vor Projektstart nie alle Storys geschrieben, sondern bestenfalls nur die ersten 1 bis 3 Sprints vorgeplant. Zu einem frühen Zeitpunkt besteht das Backlog also eher aus Features (SAFe) oder Epics (SCRUM).
Dennoch sind es grobe funktionale Beschreibungen, die den Scope mindestens des MVP (minimum viable product) beschreiben sollten. Sollte auch das nicht möglich sein, können die Preise zumindest für ein PI (Product Increment – ein ca. 4 Sprints dauernder Meilenstein) ermittelt werden.
Alle Features werden in einem Product Backlog zusammengeführt. Damit ist der Scope vollständig, wenn auch sehr grob beschrieben.
Nun gilt es für diesen Funktionsumfang ein möglichst objektives Maß zu finden, welches später als Faktor in unserer Gleichung zur Anwendung kommen kann.
Story Points
Scrum kennt so ein Maß: die Story Points. In der Literatur werden Story Points allgemein als eine Einheit für die Komplexität – gemeint ist hier konkret der Implementierungsaufwand – einer Story eingeführt. Und damit werden Story Points für das Vorhaben, für den im Product Backlog definierten Scope einen Festpreis zu ermitteln, sehr problematisch.
Überhaupt ist die Anwendung von Story Points in der Theorie noch einigermaßen einleuchtend begründet, in der Praxis allerdings umstritten. Warum?
Erstens repräsentieren Story Points kein objektives Maß sondern sind eine rein subjektive Maßeinheit, die den relativen Komplexitätsgrad (sprich Implementierungsaufwand) einer Story lediglich im Verhältnis zu anderen Stories angibt. Und die Dimension wird vom Team definiert, weshalb SAFe heute schon sogenannte normalisierte Storypoints vorschlägt.
Anders als in der öffentlichen Diskussion um Story Points halte ich das für sich genommen noch nicht für problematisch, zumindest dann nicht, wenn ich hier „subjektiv“ mit „team- und projektspezifisch“ übersetzen kann und davon ausgehe, dass auch das Team diese Einschätzung trifft.
Das Problem liegt eher in der Einheit selbst, nämlich als Einheit für die Komplexität einer Story. Denn damit wird die Perspektive gewechselt, weg von der funktionalen Größe (Scope) und hin zum Implementierungsaufwand bzw. wird die in SCRUM nahegelegte Trennung zwischen funktionaler Anforderung und dem Aufwand ihrer Implementierung aufgehoben.
Damit wird der oben beschriebene Ansatz der Reduktion von Komplexität gleich wieder aufgegeben und bei der Bewertung der Story hinsichtlich ihrer Komplexität müssen die oben beschriebenen über hundert Faktoren sofort wieder mitgedacht werden.
Dies aber kann zu einem anderen Zeitpunkt als dem Sprint-Planning, in dem sich das Team intensiv mit der Schätzung der Story beschäftigt, nicht hinreichend geleistet werden. Zum Zeitpunkt des Sprint-Plannings aber, könnte als Einheit dann auch gleich Stunden verwendet werden.
Sollen Story Points also für die Festpreis Findung verwendet werden, dann müssen sie mindestens viel früher geschätzt werden. In der Regel passiert das durch einen erfahrenen Architekten, dem dann aufgebürdet wird, sowohl die funktionale Größe als auch die vielen anderen Faktoren in Einem einzuschätzen. Ich denke es ist leicht nachvollziehbar, dass diese Übung zwar schnell ausgeführt werden kann, allerdings mindestens nur sehr ungenaue Schätzwerte liefert.
Functionpoints
Es gibt eine andere Möglichkeit, ein geeignetes Maß zu ermitteln: die Function Point Analyse. Hinter Story-Points und Function-Points stehen fundamental andere Konzepte.
Kurz gesagt, während Story-Points eine subjektive Einheit für die Komplexität einer Story ist, sind Function-Points ein objektives – also team- und projketunabhängiges – Maß für die reine funktionale
Größe einer Anforderung. Funktionale Anforderungen werden damit unmittelbar vergleichbar, egal ob sie zum Beispiel völlig neu entwickelt werden, oder in einer bereits existierenden, historisch gewachsenen und schlecht dokumentierten Anwendung mit weitreichenden Refactorings hineinimplementiert werden. Wir alle wissen, dass allein zwischen diesen beiden Szenarien im Extremfall Aufwandsfaktoren im zweistelligen Bereich liegen können.
Function-Points sind ein weitestgehend objektives Maß, da sie nicht geschätzt, sondern nach klaren und einfachen Regeln gezählt werden. Die Einschränkung ‚weitestgehend‘ unterstellt, dass es bei der Interpretation der Zählregeln gewiss auch Spielräume gibt. Untersuchungen zufolge sind diese bei erfahrenen Function-Point-Analysten nicht größer als 10 Prozent. Das Zählen von Function-Points macht allerdings mehr Mühe. Aber die Mühe lohnt sich.
In einem meiner Großprojekte (50 Entwickler, 3 Jahre Entwicklungszeit) hat das Zählen von ca. 8.000 Function Points für einen Function-Point-Analysten ca. 2 Wochen in Anspruch genommen. Bei einem 30 Mio Euro Projekt ist das durchaus akzeptabel.
Ein weiterer Vorteil ist, dass der bei der Zählung erstellte Funktionsbaum direkt für die Erstellung der Stories verwendet werden kann, was später das Projekt-Controlling und Scope-Management ganz wesentlich vereinfacht. Dennoch muss man als Kritik sicher gelten lassen, dass sich die Function Points in den vergangenen 30 Jahren nicht gerade durchgesetzt haben. Allerdings gab es vor 30 Jahren auch noch keine agile Entwicklung und möglicherweise waren sie ihrer Zeit einfach zu sehr voraus. Egal, ob Sie sich für Story Points oder Function Points entscheiden, also mit einem relativen oder absoluten Maß arbeiten, diese erste Bezugsgröße sollte in der Lage sein, den Scope zu beschreiben.
Aufwandsschätzung
Wenn Sie die funktionale Größe Ihres Projektes anhand der einzelnen funktionalen Anforderungen Ihres Product-Backlogs und der Summe der Fuction- oder Story Points der einzelnen Backlog-Items ermittelt haben, sind Sie schon einen großen Schritt vorangekommen.
Sie müssen jetzt nur noch einen Preis für die Implementierung eines Function- oder Story Points festlegen und dazu den Aufwand ermitteln. Hier bieten sich prinzipiell zwei Wege an. Sie können einfach in einem Vorprojekt einen Proof-of-Concept erstellen, indem Sie einen kleinen Prototyp entwickeln und daran die Gesamtkosten ermitteln.
Das hat zwei Vorteile.
Erstens können Sie am Ergebnis Ihre ursprüngliche Function- oder Story Point-Zählung verifizieren.
Zweitens erhalten Sie für die Aufwände reale Werte, sofern Sie sicherstellen können, dass der Proof-of-Concept tatsächlich repräsentativ ist. Genau hierin liegt aber oft das Problem, sodass ein solcher Proof-of-Concept nicht immer möglich ist.
Der dann nahe liegende zweite Weg ist die Anwendung einer Schätzmethode, die all die bereits mehrfach oben erwähnten Einflussfaktoren berücksichtigt. Die COCOMO (Constructive Cost Model) Schätzung beispielsweise ist so ein algorithmisches Kostenmodell, welches genau das leistet.
Die Anwendung ist sicher nicht ganz trivial, die Schätzungen sind allerdings von hoher Präzision und vermindern die wirtschaftlichen Risiken signifikant und Sie können Ihren Kunden und Ihrem Management ruhigen Gewissens (weil absolut nachvollziehbar) Ihren Festpreis präsentieren.
Scope Changes
Die Vorgehensweise, den funktionalen Scope Ihres Projektes mit einem Maß, wie den Function-oder Story Points zu beschreiben und dann einen Preis für die Implementierung eines Function- oder Story Points zu ermitteln hat noch einen ganz entscheidenden Vorteil, der sich insbesondere in Projekten, in denen SCRUM zum Einsatz kommt, auszahlt.
Sie können Ihren Kunden ganz pauschal und abstrakt die Entwicklung von Funktionalität zum Festpreis anbieten, selbst wenn diese noch gar nicht definiert ist.
Da Sie wissen, was die Implementierung von Funktionalität (Function-Points) unabhängig von der konkreten funktionalen Anforderung kostet, können Sie jeden Scope Change sehr einfach und transparent handeln.
Sie vereinbaren mit Ihrem Kunden, dass der Preis für eine bestimmte Anzahl von Function-oder Story Points gilt und falls der Kunde bei der Ausgestaltung der einzelnen Stories im Verlauf des Projektes diese Zahl überschreitet, also der Scope erweitert wird, erhöht sich der Preis entsprechend automatisch.
Dabei haben Function Points gegenüber Story Points natürlich Vorteile. Mindestens sollte man bei Story Points dann, wie von SAFe vorgeschlagen, die normalisierte Variante verwenden, sonst werden teamübergreifende Bewertungen ziemlich kompliziert.
Im Gegenzug erhält der Kunde die Möglichkeit durch Priorisierung aktives Scope-Management zu betreiben und für jede Story den funktionalen Umfang sehr fein zu steuern.
Ein weiterer Vorteil der Verwendung von Function Points: Da es sich bei der Function-Point-Analyse um eine neutrale und objektive Zählung handelt, können Sie mit Ihren Kunden bei Bedarf auch einen unabhängigen Function-Point-Analysten, der das Vertrauen beider Parteien genießt, einbinden.
Projekte dieser Art verlaufen in der Regel erheblich stressfreier, da sich der Kunde auf den Scope konzentrieren kann und der IT Dienstleister sich einzig mit der Implementierung beschäftigen muss, was in der Regel bereits herausfordernd genug ist.
