Einführung in Cost of Delay

Cost of Delay
Von Sebastian Schneider // 07.09.2018 // 0 Kommentare

Meine Einführung in Cost of Delay soll dir helfen eine neue Blickweise auf die sogenannten Verzögerungskosten zu bekommen. Aufgabe des Product Owner ist es, eine Sortierung der Elemente in seinem Backlog vorzunehmen. Der Scrum Guide beschreibt nicht wie diese Sortierung vorgenommen wird. Du selbst kannst die konkrete Ausprägung diese Art der Sortierung bestimmen und diese Sortierung mit den Verzögerungskosten durchzuführen.

Die genannten Verzögerungskosten stelle ich in meiner Einführung in Cost of Delay vor und zeige dir dabei die wichtigsten Komponenten.

Cost of Delay - der Ursprung

Donald Reinertsen hat in seinen Büchern einen ökonomischen Blickwinkel auf die Produktentwicklung seiner über 30 jährigen Berufserfahrung gelegt. In mehren Prinzipien hat er sein Buch gegliedert und beleuchtet die unterschiedlichsten Themen rund um das Thema der Produktentwicklung.

Was genau sind Verzögerungskosten?

Don Reinertsen:

If you only quantify one thing, quantify the cost of delay

Quelle: The Principles of Product Development Flow

Geld, das du verlierst, wenn du nicht lieferst

Wie du am Namen Verzögerungskosten oder Cost of Delay bereits erkennen kannst, geht es darum, dass du etwas "verzögert" an den Markt bringst und diese Verzögerung dich Geld kostet.

Verzögerungskosten treten immer auf und sind grundsätzlich einmal nicht schlimm. Wir wollen lediglich möglichst wenig von diesen "bezahlen". Denn wenn du es schaffst, deine Abarbeitung optimal zu bestimmen, dann hast du am wenigsten dieser Verzögerungskosten.


Um das zu erreichen, arbeiten wir mit Abarbeitungsstrategien wie dem Weightest Shortest Job First (WSJF).

Wie du Verzögerungskosten darstellst

Cost of Delay - Verzögerungskosten

Die Verzögerungskosten lassen sich am besten als eine Fläche darstellen. Durch die Reihenfolge der Abarbeitung der Aufgaben erzeugen Sie Kosten, nämlich die Verzögerungskosten aller weiteren Aufgaben.

Diese Darstellung hat Don Reinertsen auch in seinem Buch vorgestellt und bei längerer Betrachtung wird auch klar, dass diese Darstellung gut zeigt, wo die Kosten liegen - direkt vor der entsprechenden Aufgabe.

Die gesamte Fläche der Verzögerungskosten (hier organge dargestellt) drücken die Kosten aus, die wir zu "bezahlen" haben. Um diese Fläche zu bestimmen, können wir dem nachstehenden Algorithmus folgen:

  • Das erste Element, das wir umsetzen, hat keine Verzögerungskosten, denn es wartet nicht. Die Umsetzung kann sofort beginnen.
  • Das zweite Element kann dann umgesetzt werden, wenn das erste Element fertig mit der Umsetzung ist. Es kann also dann starten, wenn die Dauer des ersten Elements verstrichen ist.
  • Jedes weitere Element, muss warten, bis der Vorgänger umgesetzt ist und dann kann beginnen.

Sequentiell vs. Parallelität

Bei der Einführung in Cost of Delay kommt immer gerne wieder eine Frage oder ein Argument auf. Angebracht wird gerne, dass die Darstellung ja nun sehr sequentiell ist und man in der eigenen Organisation doch Dinge parallelisieren könne.

Das ist grundsätzlich richtig. Das ändert an den Verzögerungskosten aber nichts. Diese treten trotzdem auf, wenn du tatsächlich die Dinge parallel abarbeiten kannst, dann hast du - wenn die Kapazität wirklich vorhanden ist - die Chance mehrere dieser Themen umzusetzen.

Zudem wissen wir auch, dass negatives Multitasking schädlich ist. Es sei aber hier festgehalten, dass es natürlich bei mehreren Teams möglich ist, dass Sie an mehreren Product Backlog Items arbeiten können.

Ab wann treten Verzögerungskosten auf?

Verzögerungskosten treten immer dann auf, wenn du etwas umsetzt (zum Beispiel ein neues Feature aus deinem Backlog) und es aber nicht gleich tun kannst. Häufig liegt das daran, dass du gerade noch etwas anderes bearbeitest und keine Möglichkeit hast, mit dem neuem Product Backlog Item anzufangen. Die Aufgabe oder dein Feature bleibt einfach liegen und wartet auf die Umsetzung. Dieses Warten ist die Verzögerung, die etwas kostet und damit in Verzögerungskosten oder auch Cost of Delay resultiert.

Weightest Shortest Job First

Der Weightest Shortest Job First (WSJF) ist eine Abarbeitungsstrategie, um Ihre Verzögerungskosten möglichst gering zu halten. Daneben gibt es andere Möglichkeiten deine Abarbeitungsstrategie zu wählen. So kannst du auch FIFO (first in, first out) wählen oder andere denkbare Strategien. 

Die Abarbeitungstrategie "nach maximalen Wert des Kunden" ist ebenso eine Strategie - bestimmen, was dieser maximale Wert ist, musst du als Product Owner selbst.

Den Weightest Shortest Job First (WSJF) bescheibt Don Reinertsen in seinem Buch mit Wert durch Dauer.

Wie bestimmen Sie Cost of Delay?

Bestimmung des Wertes

Ziemlich schwierig finde ich persönlich für mich den Wert zu fassen. Ob etwas für mich Wert hat oder nicht, ist nun (leider oder zum Glück) oft subjektiv. Wenn wir aber ein gemeinsames Verständnis über eine Priorisierung etablieren wollen, dann brauchen wir ein gemeinsames Verständnis. Wichtig ist und bleibt aber immer die Konzentration auf die Kundenmehrwert.

Aus diesem Grunde haben sich wahrschheinlich auch schon unterschiedliche Sichten auf das Thema gebildet. Ich möchte dazu zwei, die mir bekannt sind, vorstellen. 

Der Wert ist das, was für Unternehmen am wichtigsten ist. Darauf sollte sich das Unternehmen fokussieren. Ist kein Verständnis über den Wert vorhanden und wie dieser gemessen werden kann, optimiert sich das System (Unternehmen) nach anderen Parametern!!

Black Swan Farming

Joshua Arnold von Black Swan Farming hat durch seine lange Erfahrung im Bereich von Cost of Delay in seinen Projekten folgende Beschreibung von Wert erstellt. Mit dem CD3 zeigt er seine Definition von Wert.

  • Business Value of the feature
  • How value decays over time
  • Information discovery Value

Scaled Agile Framework

Dean Leffingwell hat nach dem Buch von Donald Reinertsen das Framework hinsichtlich Verzögerungskosten angepasst. Spätestens auf der Feature Ebene findet eine Anwendung der Weightest Shortest Job First statt.

Dabei beschreibt das Scaled Agile Framework (SAFe) den Wert als drei Komponenten:

  • Business Value
  • Time Criticality
  • Opportunity | Risk Reduction

Die Kritik an der Berechnung vom SAFe Framework orientiert sich in meiner Augen überwiegend daran, ob es sinnvoll ist relativ bestimmte Werte zu addieren und ob das Ergebnis dann sinnvoll und valide ist. Ein weiterer Kritikpunkt ist, dass die Time Critically bereits durch die Dauer abgedeckt sei und diese bereits im Nenner vorhanden ist.

Ich bin in diesem Punkt recht pragmatisch und kann aus der Erfahrung sagen, dass es den Menschen in den Organisationen als Anhaltspunkt für den Start mehr als helfen kann mit so einer Formel zu starten. 

Wichtig sei hier auch noch einmal zu nennen, dass der WSJF nicht aus SAFe stammt - diese Aussage begegnet mir in der Realität immer wieder. Ebenso wie Organisationen die  Verzögerungskosten nutzen, aber kein SAFe machen.

Was ist der Wert für dich?

Du musst für deine Organisation, für deinen Kontext eine Möglichkeit finden, den Wert zu adressieren. Ich habe selten erlebt, dass Unternehmen ein Preisschild an den Wert kleben können, sondern viel mehr beobachtet, dass eine relative Bestimmung leichter fällt.

Ob das bei dir auch so ist, hängt natürlich davon ab, was du entwicklst und ob solche Daten verfügbar sind. Deswegen ist es wichtig zu verstehen, dass es gerade nicht richtig oder falsch bei der Auswahl gibt.

Bestimmung der Dauer

Bei der Dauer arbeiten viele Organisationen mit einer Größenangabe. Es können die Story Points sein, es können Wochen sein, es können Sprints sein. Oder du nutzt relative Werte anhand der Fibonacci Folge. Wichtig ist auch hier nur, bleibe konsistent in deiner Wahl. 

Cost of Delay für Scrum

Bewusstsein schaffen

Ich kenne genug Diskussionen bei denen nicht klar, warum ein Feature vor dem anderen gemacht werden soll. Die Protagonisten schweifen häufig ab und verlieren sich in Berechnungen von zukünftigen Einnahmen oder Werten.

Das Bewusstsein für Verzögerungskosten ändert sich in der Regel dann, wenn klar und transparent nachvollzogen werden kann, was Verzögerungskosten sind und wie diese zustande kommen.

Wer bestimmt den Cost of Delay?

Die Priorisierung ist Aufgabe des Product Owners

Die Hoheit über das Product Backlog liegt bei dem Product Owner. In vielen Organisationen gibt es allerdings mehr als einen Product Owner. Oft auch sogenannte Product Owner Teams ("Es kann nur einen geben"). Bevor wird das jetzt pauschal verurteilen, möchte ich kurz einen Blick darauf werden, warum das so ist:

  • Häufig sind Organisationen nicht so aufgestellt, dass es "den einen Product Owner" gibt. Die Aufgabe des Product Owners ist nun eine sehr entscheidende und da ebenso häufig ungerne Entscheidungen getroffen werden, entstehen Product Owner Teams, die mit mehreren Personen die Belange der Rolle Product Owner ausfüllen sollen.
  • Das Produkt selbst ist sehr groß, die notwendigen Skills für den Product Owner gibt es nicht in einer Person oder es gibt Tandems (wie zum Beispiel vom Fachbereich zur IT).
  • Die Organisation steckt mitten im Wandel und belegt die Rollen Product Owner mehrfach (so mit Projekt und Teilprojektleitern) und kommt aus diesem hierarchischen Gebilde nicht von heute auf morgen heraus.

Sobald du die reine Scrum Lehre verlässt und eben doch mehr als den einen Product Owner hast, kann es eine gute Idee sein, mit dem WSJF zum Beispiel das Backlog zu sortieren. Alle Product Owner bringen so das Wissen für alle Product Backlog Items ein. Dieser Zustand muss nicht final sein und kann Ihnen dann sogar bei einer späteren (De)skalierung helfen.

Alle zusammen

Lösen wir uns von dem reinen Scrum Gedanken, dann kann es zum Beispiel auf einer Portfolioebene hilfreich sein, dass wir mit mehreren Personen Priorisierungsrunden durchführen können oder  müssen, bei denen ein Weightest Shortest Job First hilfreich ist.

Verzögerungskosten einführen - so geht es!

Ich habe bereits unterschiedliche Erfahrungen mit der Einführung von Cost of Delay machen dürfen. Dabei habe ich für mich eine Vorgehensweise herauskristallisiert, die recht gut funktioniert. Diese stelle ich dir hier in der Übersicht vor.

  • Mache nichts funktionierendes kaputt. Stelle zunächst fest, wie klar und transparent eine aktuelle Sortierung bei dir funktioniert. Wenn gute Product Owner in den Teams arbeiten, kann eine Priorisierung schon sehr ähnlich zu Verzögerungskosten sein. Beobachte hier und gehen Sie aktiv in die Frage-Rolle, wenn du Unklarheiten findest. 
  • Erkläre die Verzögerungskosten. Suche dir Stakeholder und biete  einen Workshop zu diesem Thema an. Mache es kurzweilig und erläutere die Vorteile. Zeige auch einfache Rechenbeispiele, wie zum Beispiel Product Backlog Items, klassische Projekte oder Features bewertet werden können. Bereite nur wenig an der Agenda vor und konzentriere dich sich ganz auf Gespräche und Diskussionen. Finde die Pain-Points und Vorbehalte, die die Mitglieder haben.
  • Im kleinen Kreis ausprobieren. Mache ein kurzes Beispiel für alle Interessierten und nutze immer aktuelle Backlog Items. Lassen diese Backlog Items schätzen. Gehe bewusst auf die Vorbehalte ein und Lösungen.
  • Frage nach Piloten. Nicht jede Organisation hat gleich alles verstanden, die richtigen Entscheider in solchen Workshops und möchte gleich loslegen. Oft helfen kleine Experimente und Prototypen, um ein Gefühl von der Theorie in der Praxis zu bekommen.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>