Meditations on Agile

Der Product Owner im Casino: Backlogs priorisieren mit Costs of Delay und Monte-Carlo-Simulationen

Gerrit Beine

© Shutterstock / Fer Gregory

Die Priorisierung des Backlogs ist eine zentrale Aufgabe für Product Owner. Gleichzeitig ist sie eine der schwierigsten Aufgaben. Viele Methoden konzentrieren sich auf strukturelle und inhaltliche Aspekte. Dieser Artikel möchte eine Methode zeigen, wie ökonomische Aspekte in Kombination mit Simulationen als Grundlage verwendet werden können.

Die agile Community hat etliche Methoden zur Priorisierung von Product Backlogs hervorgebracht. Einige davon können schon fast als Kanon der Product-Owner-Ausbildung betrachtet werden, z. B. MuSCoW. Andere Methoden sind eigentlich eine eigene Disziplin und beziehen schon Aspekte aus der Erstellung von Geschäftsmodellen ein, z. B. Story Mapping. All diesen Methoden ist gemeinsam, dass sie einen starken Fokus auf die Inhalte der Backlog Items legen und vor allem ein gemeinsames Verständnis bei allen Beteiligten schaffen wollen. Denn Fakt ist: Ohne dieses Verständnis lassen sich Projekte nicht erfolgreich durchführen.

Neben dem Verständnis gibt es aber eine weitere Dimension, die für den Erfolg eines Projekts entscheidend ist: die Wirtschaftlichkeit. Zwar wird gerne gesagt, dass Backlog Items entsprechend ihres Kosten/Nutzen-Verhältnisses priorisiert werden sollen, es gibt aber nur wenige konkrete Vorschläge, wie sich dieser Nutzen quantifizieren lässt. An dieser Stelle setzt die Methodik der Costs of Delay (Verzögerungskosten) an. Sie ist eine hervorragende Ergänzung zu Story Mapping, Impact Mapping oder anderen Methoden und fügt den ökonomischen Blickwinkel hinzu.

Die Grundidee der Costs of Delay

Die Costs of Delay wurden von Don Reinertsen [1], [2] beschrieben und sind mittlerweile ein anerkanntes ökonomisches Werkzeug. Die Idee besteht darin, dass es neben den Kosten, die durch eine unternehmerische Aktivität entstehen, auch Kosten gibt, die entstehen, wenn diese Aktivität zu lange dauert oder ihre Ergebnisse zu spät verfügbar sind. Diese Kosten sind im einfachsten Fall entgangene Einnahmen durch Verzögerung, in komplizierten Fällen Strafzahlungen durch zu späte Lieferung oder komplexe soziale Folgen.

Oft kommt es vor, dass Costs of Delay mit Opportunitätskosten gleichgesetzt werden. Dies ist aber falsch. Opportunitätskosten sind einfach ausgedrückt entgangene Gewinne, die unternehmerische Aktivitäten hätten erzielen können. Costs of Delay entstehen, weil eine unternehmerische Aktivität gar nicht, zu spät oder nicht effizient durchgeführt wird. Reinertsen sagt, dass 85 Prozent aller Produktmanager die Costs of Delay nicht kennen. Außerdem seien Menschen im Allgemeinen sehr schlecht in der Abschätzung der Costs of Delay. In Untersuchungen hat er ermittelt, dass die Costs of Delay im Mittel um einen Faktor 50 unterschätzt werden. Er legt Produktmanagern nahe, sich intensiv mit dieser Idee zu beschäftigen und Costs of Delay tatsächlich zu quantifizieren. Natürlich sind die Costs of Delay für Backlog Items Prognosen über zukünftige Entwicklungen. Damit sind sie, je nachdem wie viel Wissen über die Zukunft verfügbar ist, mehr oder weniger exakt. Eine bewusste Beschäftigung mit den Costs of Delay hilft Product Ownern aber in jedem Fall, eine bessere Einschätzung abzugeben als das Ignorieren dieser Kosten und ein rein inhaltliches Priorisieren von Backlogs. Basierend auf den Ideen von Reinertsen gibt es vier Basismodelle der Costs of Delay:

  • Linear mit der Verzögerung steigende Kosten (Standard)
  • Kosten, die ab einem definierten Zeitpunkt entstehen (Fixed Date)
  • Plötzlich entstehende Kosten (Expedite)
  • Kosten, die wahrscheinlich entstehen, aber nicht exakt zu prognostizieren sind (Intangibles)

Im Standardfall sind die Costs of Delay zunächst gering und steigen sukzessive mit der Zeit an (Abb. 1). Die Verzögerung wird also im Laufe der Zeit immer teurer. Durch die Linearität lässt sich aber gut prognostizieren, bis wann eine Entscheidung getroffen oder ein Ergebnis fertig gestellt sein muss, um ein optimales Verhältnis zwischen Costs of Delay und der entgegenstehenden Investition zu erhalten.

 

Abb. 1: Costs of Delay im Standardfall: Die Kosten steigen ab einem definierten Zeitpunkt linear

Abb. 1: Costs of Delay im Standardfall: Die Kosten steigen ab einem definierten Zeitpunkt linear.

Ähnlich einfach lassen sich Costs of Delay handhaben, die dem Fixed-Date-Modell folgen (Abb. 2). Die Kosten steigen zwar ab diesem Zeitpunkt rapide an, da der Zeitpunkt aber bekannt ist, besteht die Möglichkeit, rechtzeitig zu handeln. Hilfreich ist das Fixed-Date-Modell insbesondere dann, wenn eine Entscheidung nicht zu früh getroffen werden soll. Denn das wäre Verschwendung.

snipp2

Abb. 2: Costs of Delay im Fall eines festen Zeitpunkts: Wird dieser Zeitpunkt erreicht, steigen die Kosten auf einen definierten Wert.

Besonders spannend sind die beiden Fälle Expedite und Intangibles. Dabei könnte man Expedite als einen Sonderfall des Fixed-Date-Modells betrachten, in dem der Zeitpunkt zu spät bekannt wurde oder bereits in der Vergangenheit liegt (Abb. 3). Ein Beispiel dafür ist ein schwerwiegender Fehler in einer produktiven Software. Hier fallen ab dem Moment des Eintretens Verzögerungskosten an, die praktisch unbegrenzt wachsen, je länger es dauert, den Fehler zu beheben. Neben solchen Fehlern können aber auch andere nicht vorhersagbare Ereignisse, wie der Eintritt eines neuen Marktteilnehmers, zu Verzögerungskosten führen, die dem Expedite-Modell folgen.

Abb. 3: Costs of Delay in einer Expedite-Situation: Die Kosten sind schon vor einer Weile entstanden, allerdings war das nicht bekannt; das bedeutet einen kontinuierlichen Verlust zum aktuellen Zeitpunkt

Abb. 3: Costs of Delay in einer Expedite-Situation: Die Kosten sind schon vor einer Weile entstanden, allerdings war das nicht bekannt; das bedeutet einen kontinuierlichen Verlust zum aktuellen Zeitpunkt.

Während sich in den drei beschriebenen Varianten die Costs of Delay in der Regel gut bis sehr gut quantifizieren lassen, ist das bei Intangibles oft nicht der Fall (Abb. 4). Es ist im Voraus nicht genau bekannt, wann die Kosten steigen werden und wie hoch; eine exakte Quantifizierung kann nur im Nachhinein erfolgen; dann kann allerdings auch aus dem Intangible ein Expedite werden. Bei den Intangibles handelt es sich um Themen wie technische Schulden, Forschungsaufgaben oder auch Investitionen in Bereichen wie Human Resources. Für solche Beispiele können die Costs of Delay häufig nur indirekt und a posteriori quantifiziert werden. Natürlich ist es aber auch in diesen Fällen sinnvoll, die Costs of Delay möglichst gut zu prognostizieren. Dies kann durch Erfahrungen und Expertise in den betreffenden Gebieten auch in ausreichender Qualität gelingen.

Abb. 4: Costs of Delay von Intangibles

Abb. 4: Costs of Delay von Intangibles

Die Herausforderung des Product Owners

Meditations on Agile

GerritIn der Kolumne “Meditations on Agile” reflektiert Gerrit Beine (adesso AG) über das Thema Agilität in der Softwareentwicklung. Einiges davon durchaus ketzerisch, anderes zutiefst spirituell. Die Entwicklung hängt vom Feedback ab. Typisch agil. Bisher erschienen:

Ein Product Owner kennt die Costs-of-Delay-Modelle, die für sein Projekt relevant sind. Einige Organisationen nutzen Costs of Delay bereits zur Bewertung von unternehmerischen Entscheidungen und ergänzen damit die üblichen Methoden wie Return on Investment (RoI), Net Present Value (NPV) oder Internal Rate of Return (IRR). Innerhalb eines Projekts oder für eine Produktentwicklung sind Costs of Delay jedoch nicht immer einfach umzusetzen. Denn die Costs of Delay eines einzelnen Features zu quantifizieren, kann eine große Herausforderung werden. Wie beschrieben, fällt es uns Menschen schwer, Costs of Delay gut zu schätzen. Eine Schätzung ist zwar immer noch besser als gar keine Betrachtung, reicht aber bei Weitem nicht aus, um gute Entscheidungen zu treffen. Vielen Organisationen fällt es schon schwer, einzelne Features von Software überhaupt mit einem ökonomischen Wert abseits des Aufwands für ihre Erstellung zu quantifizieren. Product Owner benötigen also eine Herangehensweise, die es ihnen erlaubt, eine solche Bewertung zu ermitteln.

Ist es gelungen, ein Modell zur Ermittlung der Costs of Delay einzelner Features zu erstellen, steht die nächste Herausforderung an: Costs of Delay sind kein fester Parameter. Sie verändern sich im Laufe der Zeit und hängen damit von der Reihenfolge der Features ab, die sie wiederum bestimmen sollen. Damit wird die Priorisierung des Product Backlogs für den Product Owner zu einem Optimierungsproblem.

Je nachdem, von wie vielen Aspekten die Costs of Delay bestimmt werden, ist die Berechnung dieses Optierungsproblems aufwendig. Da die Priorisierung eines Product Backlogs im Verlauf eines Projekts auch volatil ist, muss die entsprechende Berechnung regelmäßig wiederholt werden. Manchmal muss auch noch das zugrunde liegende Modell angepasst werden, weil neue Erkenntnisse gewonnen wurden oder sich Rahmenbedingungen verändert haben und natürlich, weil bereits Teile des Projekts realisiert wurden. Der Fokus der Priorisierung für ein Projekt oder eine Produktentwicklung sollte immer auf der Frage liegen, was als Nächstes getan werden muss. Diese Aspekte sprechen dafür, eine Monte-Carlo-Simulation zu nutzen, um eine Priorisierung für das Product Backlog zu ermitteln. Monte-Carlo-Simulationen erzeugen viele verschiedene Priorisierungen des Product Backlogs und ermitteln jeweils die kumulierten Costs of Delay. Mit relativ wenig Aufwand erhält ein Product Owner ein priorisiertes Backlog das auf Basis des zum Zeitpunkt der Priorisierung verfügbaren Wissens mit großer Wahrscheinlichkeit optimal ist.

Wirkmodelle als Basis der Monte-Carlo-Simulation

Um eine solche Monte-Carlo-Simulation durchführen zu können, benötigt man zunächst ein Wirkmodell, mit dem sich die unterschiedlichen Treiber für die Costs of Delay und damit die Priorität von Backlog Items beschreiben lassen. Ein Beispiel für ein solches Wirkdiagramm ist in Abbildung 5 dargestellt. Das Diagramm zeigt die Beziehungen und Wirkungen unterschiedlicher Aspekte der Features in einem Projekt. Werden die Aspekte pro Feature bewertet, kann das Modell Grundlage für eine Monte-Carlo-Simulation sein. Verschiedene Treiber wirken verstärkend (+) oder abschwächend (-) auf einander und letztendlich auf die Costs of Delay. Diese wiederum wirken verstärkend auf die Priorität eines Backlog Items. Je höher die Costs of Delay sind, desto höher die Priorität des Backlog Items.

Abb. 5: Wirkdiagramm für ein Costs-of-Delay-Modell

Abb. 5: Wirkdiagramm für ein Costs-of-Delay-Modell

Welche Aspekte eine Rolle für ein solches Wirkdiagramm spielen können, ist dabei von Projekt zu Projekt unterschiedlich. Fundamental ist in jedem Fall das Geschäftsmodell oder der Business Case, die hinter einem Produkt oder Projekt stecken. Diese liefern bereits viele Aspekte, die in ein solches Wirkdiagramm einfließen können.

Das Wirkdiagramm kann anders als rein monetäre Mechanismen wie IRR oder NPV auch intangible Aspekte enthalten. Damit wird es möglich, die Wirkung von Themen wie Usability, Rechtskonformität, IT Security oder auch Umweltschutz auf die Costs of Delay zu modellieren. Methoden zur Quantifizierung solcher Intangibles hat Douglas Hubbard ausführlich in seinem Buch „How to Measure Anything“ [3] beschrieben.

Ein solches Wirkdiagramm und das zugrunde liegende Modell können groß und kompliziert werden. Die Arbeit mit dem Wirkdiagramm ist dennoch leicht, weil sich die einzelnen Themen zunächst unabhängig voneinander betrachten lassen. Ein Usabilityexperte kann die Wirkung einzelner Backlog Items auf die User Experience bewerten, während eine Juristin das Gleiche für die Rechtskonformität machen kann. Im Modell wird das Wissen aller zusammengeführt. Das Wirkdiagramm ist dadurch als Erklärung der Zusammenhänge der Priorisierung im Dialog mit Stakeholdern hilfreich. Erfahrungen zeigen, dass viele Stakeholder sich wohler fühlen, wenn sie nur Aspekte ihrer Domäne beurteilen müssen und nicht über die Wichtigkeit eines Backlog Items als Ganzes entscheiden sollen. Damit kommt die Dekonstruktion der Treiber für die Costs of Delay den Menschen entgegen, hilft Schätzungen zu verbessern und ermöglicht es, schwierige Themen, die keinen direkten monetären Nutzen liefern, korrekt zu priorisieren.

Auf ins Casino: Die Monte-Carlo-Simulation

Mit den gewonnenen Daten und dem Modell lässt sich nun eine Monte-Carlo-Simulation füttern. Diese erzeugt eine große Menge zufälliger Reihenfolgen der bewerteten Backlog Items und berechnet für jedes Backlog Item die Costs of Delay anhand der Position im Backlog, der voraussichtlichen Umsetzungsgeschwindigkeit des Teams und natürlich der anderen beschriebenen Wirkungen. Die kumulierten Costs of Delay sind das Maß für die Güte der jeweiligen Priorisierung. Dabei gilt: Eine Priorisierung, bei der geringere Costs of Delay entstehen als bei den vorher berechneten, ist eine bessere Priorisierung.

Üblicherweise werden in einer solchen Monte-Carlo-Simulation nicht alle möglichen Priorisierungen berechnet. Die Simulation wird entweder nach Erreichen einer definierten Anzahl von Durchläufen oder nach Ablauf eines Zeitfensters beendet. Die bis dahin ermittelte beste Priorisierung wird dann als Entscheidungsgrundlage verwendet. Natürlich kann es sein, dass diese Priorisierung nicht die bestmögliche Priorisierung ist. Das ist sogar wahrscheinlich. Sie ist aber, unter der Voraussetzung, dass das Wirkmodell durchdacht ist und eine genügend große Anzahl von Simulationen stattgefunden hat, ausreichend gut, um zu entscheiden, was als Nächstes getan wird.

In regelmäßigen Abständen, wenn z. B. das nächste Backlog Grooming, Replenishment oder Release Planning ansteht, wird die Simulation erneut durchgeführt und die Priorisierung der Backlog Items erneut festgelegt. Dabei kann es sein, dass Backlog Items herausfallen, neue hinzukommen, Bewertungen oder sogar das Wirkmodell verändert wurden. Die Monte-Carlo-Simulation liefert zuverlässig die wahrscheinlich beste Reihenfolge für das Product Backlog.

Fazit

Product Owner benötigen Werkzeuge, um gute und nützliche Produkte mit ihren Teams zu bauen. Neben vielen bekannten Werkzeugen, die vor allem auf inhaltliches Verständnis und Kollaboration abzielen, werden auch solche, die ökonomische Aspekte handhabbar machen, immer wichtiger. Dabei müssen insbesondere die nicht materiellen und indirekt wirkenden Aspekte berücksichtigt werden. Die wenigsten Product Owner können die dafür notwendigen Bewertungen allein stemmen. Entwicklungsteams und Stakeholder müssen sie dabei unterstützen. Das gelingt am effektivsten, wenn alle ihr Domänenwissen sinnvoll einbringen können und dieses gezielt zusammengeführt wird. Aufgaben wie die Priorisierung des Backlogs können Product Owner dann getrost Computern überlassen. Das hat neben den Effekt, dass es Zeit für wichtige Aufgaben schafft, noch die Vorteile, dass es unpolitisch ist und allen Beteiligten entgegenkommt, weil sich niemand mehr gegen etwas entscheiden muss. Außerdem macht das Entwickeln einer solchen Simulation jede Menge Spaß.

Geschrieben von
Gerrit Beine
Gerrit Beine
Gerrit Beine ist Managing Consultant bei der adesso AG mit den Schwerpunkten Agilität und Softwarearchitektur. Er ist regelmäßig als Sprecher auf Konferenzen zu treffen und beschäftigt sich gerne mit außergewöhnlichen Fragestellungen zur Softwareentwicklung.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: