Agile Methode: Kosten ermitteln
Auf den ersten Blick scheinen Kosten in der agilen Produktentwicklung nur eine untergeordnete Rolle zu haben, während sie im klassischen Projektmanagement sehr dominant sind. Dieser Eindruck täuscht allerdings. Wenn wir uns mit der Priorisierung von Anforderungen beschäftigen, dann basiert der Wert einer Funktionalität auf der klassischen kaufmännischen Sichtweise:
Wert = Nutzen - Aufwand.
Der Aufwand wird dabei in Story Points, Idealtagen und ähnlichem geschätzt. Irgendwann innerhalb der Planung, wird dann ein Zusammenhang zwischen einem Personentag und den Story Points, oder anderen Schätzgrößen hergestellt.
Der nächste Schritt von dem Personentag zu den Personentagessätzen ist dann nur noch sehr klein - und damit sind wir wieder in der üblichen Welt der altbekannten Projektkostenrechnung angekommen.
Die Kosten für eine Timebox sind sehr leicht zu berechnen.
- Die Dauer einer Timebox ist bekannt und bleibt über die Dauer der Produktentwicklung fix.
- Das Team (incl. Product Owner und Scrum Master) bleibt (im Idealfall) über den gesamten Produktentwicklungsprozess zusammen.
- Alle Mitarbeiter im Team sind der Produktentwicklung zu 100% ihrer Arbeitszeit zugewiesen.
Damit können die Personalkosten innerhalb einer Timebox leicht ermittelt werden. Die altbewährte Berechnung der Personenstunden kann hier genutzt werden. Über die Zahl der geplanten Timeboxes ergibt sich die Höhe der Gesamtkosten.
Wenn die durchschnittliche Höhe der Story Points pro Timebox als Team Velocity bekannt ist, können auch die erwarteten Kosten pro Story Point errechnet werden.
Die Kostenberechnung ist also recht einfach, soweit primär Mitarbeiterkosten entstehen. Wenn das Produkt, das erstellt werden soll, zusätzlich teure Materialen oder Dienstleistungen benötigt, die bei den einzelnen Funktionalitäten variieren, dann wird die Berechnung der Kosten wesentlich schwieriger.
Nehmen wir einmal die unspezifische Anforderung: "Wir brauchen ein Auslieferungsfahrzeug."
Wenn wir klassisch vorgehen würden, dann würden wir jetzt genau festlegen, wie das Fahrzeug beschaffen sein könnte und dann berechnen lassen, wie hoch die Materialkosten sind. Wir könnten auch verschiedene Kostenvoranschläge einholen, die basierend auf einem genauen Pflichtenheft erstellt werden. Die Unsicherheiten und Ungenauigkeiten und der Aufwand bei der Erstellung und Änderung solcher Berechnungen sind ja hinlänglich bekannt. Ich werde sie hier also nicht erörtern. Wir erhalten als Kalkulationsbasis eine Zahl, die auf der Multiplikation von Wahrscheinlichkeiten mit Wahrscheinlichkeiten basiert. Die genauen Kosten bleiben bis zur Fertigstellung des Daches unsicher.
Wenn wir agil vorgehen, dann steht diese unspezifische Anforderung zunächst einmal im Product Backlog und wird dann genauer spezifiziert, wenn wir wissen, wie genau das Fahrzeug beschaffen sein soll und wie sich die Materialpreise entwickelt haben. Erst dann erfolgt eine genaue Beschreibung. Danach erfolgt eine Kalkulation der Kosten, die wesentlich weniger unsicher ist, als die "frühe Kalkulation". Die genauen Kosten kennen wir auch in dieser Situation erst nach der Fertigstellung des Daches.
Was verändert sich durch das agile Vorgehen?
In dem klassischen Vorgehen wird, bevor mit dem Projekt begonnen wird, genau spezifiziert und berechnet, was gebraucht werden wird. Die Kosten sind - mit den üblichen Unsicherheiten bekannt. Im Verlauf des Projektes erkennen wir, dass wir etwas anderes brauchen. Spezifizieren genau und berechnen die Kosten mit den üblichen Unsicherheiten. Dann erkennen wir, dass wir etwas anderes brauchen, spezifizieren genau und berechnen die Kosten mit den üblichen Unsicherheiten. Und so weiter. In dem letzten Zyklus spezifizieren und kalkulieren wir genau und erstellen die Funktionalität. Ist sie fertig, kennen wir die Kosten genau.
Im agilen Vorgehen leben wir mit der Unsicherheit, berechnen, spezifizieren erst kurz vor der Leistungserstellung mit sehr hoher Sicherheit. Erst wenn die Funktionalität fertig ist, kennen wir sie genau.
Welches Vorgehen ist jetzt besser?
- Bei dem klassischen Vorgehen, ist die Unsicherheit kleiner, da wir zumindest eine "grobe Richtung" der Kosten haben. Dafür ist der Aufwand zu Anfang größer.
- Im Verlauf des klassischen Vorgehens ändern wir die Spezifikation / Kostenschätzungen mehrmals mit zusätzlichem Aufwand.
- Bei dem agilen Vorgehen ist die Unsicherheit größer, denn es gibt noch nicht einmal eine "grobe Richtung". Es entsteht kein Aufwand.
Die letztendliche Spezifikation ist in beiden Fällen sehr ähnlich. Die Endkosten sind identisch. Das agile Vorgehen ist mit weniger Aufwand und einer größeren Unsicherheit verbunden.
Aber: Ist das "agile Vorgehen" genau wie in dem Bild oben beschrieben?
- Im Product Backlog wird jede Anforderung in eine Hierarchie gebracht und der Aufwand wird geschätzt. Lediglich die Schätzung ist nicht so genau, wie in dem klassischen Vorgehen.
- Erfolgt eine Änderung einer Anforderung, dann wird das Product Backlog geändert. Im agilen Vorgehen reden wir von Backlog Pflege. Im Rahmen dieser Backlog Pflegen, erfolgt natürlich auch eine "Neuschätzung" des Aufwandes.
- Die Änderungen im Product Backlog erfolgen in Abstimmung des Product Owners mit den Stakeholdern und den Leistungserstellern.
Und schreibt das "klassische Projektmanagement" (nach PMI, Prince2, GPM-IPMA) das Vorgehen vor, dass in dem Bild oben beschrieben wurde?
- Die Anforderungen der Stakeholder werden in einer Leistungsbeschreibung erfasst. Hier folgt eine Hierarchisierung der Ziele und in der Planung ein Schätzung des Aufwandes, der notwendig ist, um diese Ziele zu erreichen.
- Der Aufwand der Anforderungen wird im Verlauf des Planungsprozesses geschätzt. Die Anweisung in allen Systemen: "so genau wie nötig, so grob wie möglich". Es wird immer empfohlen bei frühen Schätzungen eine "von ... bis" Spanne anzugeben.
- Eine Änderung der Anforderungen und des Planes ist jederzeit möglich, sofern der Änderungsprozess eingehalten wird. Der besagt: Änderungen müssen mit den Stakeholdern besprochen und von den Auftraggebern genehmigt werden. Ein Änderungsantrag beinhaltet: Beschreibung der Änderung, Beschreibung der Folgen der Änderung in Bezug auf Kosten, Budget, Risiken, etc...
Wie unterschiedlich sind die Vorgehensweisen also wirklich? Liegen die Probleme, die in dem klassischen Vorgehen liegen, wirklich in den Projektmanagement-Methoden begründet? Und ist die Problemlösung, die im agilen Vorgehen liegt, so unterschiedlich von dem "klassischen Projektmanagement"?
Oder sind die Probleme in der Interpretation des Vorgehens zu suchen? Und besteht dann nicht das Risiko, dass genau die gleichen Interpretationsprobleme bei der Anwendung der agilen Methoden erneut gemacht werden?
Die Frage, welches Vorgehen jetzt besser ist, bleibt weiterhin bestehen.
Die wesentlichen Fragen reduzieren sich auf die klassische Abwägung, die bei Schätzungen immer im Mittelpunkt stehen:
- Wie sicher ist eine Vorhersage?
- Wie dringend brauche ich eine sichere Vorhersage?
- Mit welchem Aufwand kann ich die Sicherheit der Vorhersage erhöhen?
Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org
I