Cost of Delay

Einführung in Cost of Delay

Meine Einführung in Cost of Delay soll Ihnen 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. Sie selbst können die konkrete Ausprägung diese Art der Sortierung bestimmen und die diese Sortierung mit den Verzögerungskosten durchzuführen ist eine Möglichkeit.

Die genannten Verzögerungskosten stelle ich in meiner Einführung in Cost of Delay vor und zeige Ihnen 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 Sie verlieren, wenn Sie nicht liefern

Wie Sie am Namen Verzögerungskosten oder Cost of Delay bereits erkennen können, geht es darum, dass Sie etwas "verzögert" an den Markt bringen und diese Verzögerung Sie dann Geld kostet.

​Verzögerungskosten treten immer auf und sind grundsätzlich einmal nicht schlimm. Wir wollen lediglich möglichst wenig von Ihnen "bezahlen". Denn wenn Sie es schaffen, Ihre Abarbeitung optimal zu bestimmen, dann haben Sie am wenigsten dieser Verzögerungskosten.


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

​Wie Sie Verzögerungskosten darstellen

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 de​r 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 Sie tatsächlich die Dinge parallel abarbeiten können, dann haben Sie - 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 Sie etwas umsetzen (zum Beispiel ein neues Feature aus Ihrem Backlog) und es aber nicht gleich tun können. Häufig liegt das daran, dass Sie gerade noch etwas anderes bearbeiten und keine Möglichkeit haben, damit anzufangen. Die Aufgabe oder Ihr 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 Ihre Abarbeitungsstrategie zu wählen. So können Sie 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, müssen Sie 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

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 Sie?

Sie müssen für Ihre Organisation, für Ihren 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 Ihnen auch so ist, hängt natürlich davon ab, was Sie entwicklen 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 de​r 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 Sie nutzen relative Werte anhand der Fibonacci Folge. Wichtig ist auch hier nur, bleiben Sie konsistent in Ihrer 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 Sie die reine Scrum Lehre verlassen und eben doch mehr als den einen Product Owner haben, 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 Ihnen hier in der Übersicht vor.

  • Machen Sie nichts funktionierendes kaputt. Stellen Sie zunächst fest, wie klar und transparent eine aktuelle Sortierung bei Ihnen funktioniert. Wenn gute Product Owner in den Teams arbeiten, kann eine Priorisierung schon sehr ähnlich zu Verzögerungskosten sein. Beobachten Sie hier und gehen Sie aktiv in die Frage-Rolle, wenn Sie Unklarheiten finden. 
  • Erklären Sie die Verzögerungskosten. Suchen Sie sich Stakeholder und bieten Sie einen Workshop zu diesem Thema an. Machen Sie es kurzweilig und erläutern Sie die Vorteile. Zeigen Sie auch einfache Rechenbeispiele, wie zum Beispiel Product Backlog Items, klassische Projekte oder Features bewertet werden können. Bereiten Sie nur wenig an der Agenda vor und konzentrieren Sie sich ganz auf Gespräche und Diskussionen. Finden Sie die Pain-Points und Vorbehalte, die die Mitglieder haben.
  • Im kleinen Kreis ausprobieren. Machen Sie ein kurzes Beispiel für alle Interessierten und nutzen Sie aktuelle Backlog Items. Lassen Sie diese Backlog Items schätzen. Gehen Sie bewusst auf die Vorbehalte ein und Lösungen, die Sie sich dafür gedacht haben.
  • Fragen Sie 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.

Leave a Reply 0 comments

Leave a Reply:







>