On Lean and Agility

Nochmal zum Thema Cost of Delay, also zu den Verzögerungskosten, die auftreten, wenn ein Produkt oder Feature zu langsam fertig wird. Diese Kosten werden gemessen in (ungefähren) Geldbeträgen, die verpassten oder verzögerten Gewinnen entsprechen. Auf den ersten Blick erscheint das Zwangsläufig und nicht weiter erwähnenswert, bei näherer Betrachtung ist darin aber eine eigentlich offensichtliche Implikationen enthalten, die aber manchmal vergessen wird.

Um Verspätungskosten finanziell messen oder schätzen zu können, ist etwas ganz Grundlegendes nötig: ein Business Case des Produkts oder Features nämlich, für das diese Kosten ermittelt werden sollen. Das ist in vielen Fällen auch gut möglich, etwa bei neuen Autos oder Computerspielen, bei neuen Funktionen komplexer und abstrakter Produkten wie z.B. Betriebssystemen oder Online-Portalen ist es dagegen deutlich schwieriger und ggf. sogar unmöglich.

Noch am Einfachsten ist es in Fällen, in denen diese Funktionen kostenpflichtig gekauft oder abonniert werden können. In derartigen Konstellationen lassen sich nach Fertigstellung die Gewinne rückwirkend auf die "verpassten" Monate übertragen, oder alternativ kann bereits während der Planung von einem voraussichtlichen Gewinn ausgegangen werden, dessen drohendes Verpassen ggf. kurzfristige Mehraufwände rechtfertigen kann.

Schwieriger wird es, wenn neu erstellte Features nicht separat monetarisierbar sind. Ein Umweg den man hier gehen kann, ist der über die Marktforschung: wenn eine Neuerung ein Differenzierungsmerkmal ist (oder ein Differenzierungsmerkmal eines Wettbewerbers egalisiert) kann man annehmen, dass Umsätze (und damit Gewinne) ganz oder teilweise auf sie zurückzuführen sind, was sich dann annäherungsweise in Geld quantifizieren lässt.

Praktisch unmöglich wird die Ermittlung von Cost of Delay, wenn die jeweilige Funktionalität weder separat vermarktet wird, noch von Kunden als Differenzierungsmerkmal wahrgenommen wird (oder überhaupt separat wahrgenommen wird). Ein internes Diagnose-Programm wäre ein Beispiel dafür. Natürlich ist es aus Produktsicht sinnvoll und mehrwertstiftend, es ist aber nichts, das man einem Kunden in Rechnung stellen oder ihm gegenüber vermarkten könnte.

Für derartige Funktionen ist eine separate Ermittlung von Verspätungskosten schlicht nicht machbar, was eigentlich auch kein Problem ist - schliesslich müssen sie nicht zwanghaft für jedes Feature gemessen werden. Entweder fallen sie ganz aus derartigen Betrachtungen heraus, oder sie entsprechen der kompletten Verspätungskostensumme des Gesamtprodukts - dann nämlich, wenn dieses ohne die einzelne Funktion nicht verkauft werden kann oder darf.

Der Vollständigkeit halber: Wird in überregulierten Umgebungen versucht, eine kategorische Anwendung dort zu erzwingen, wo das eigentlich nicht geht, ist meistens Cargo Cult die Folge. Dann kann es z.B. sein, dass für Funktionen ohne Business Case einer "nach Bauchgefühl" ermittelt wird, z.B. mit Planning Poker. Diesen Wert kann man dann in die Dokumentation schreiben um den Vorganben gerecht zu werden, es ist aber nicht mehr als Business-Theater, das man auch sein lassen kann.

Manchmal hilft bei der Vermittlung komplexer Sachverhalte ein Video ungemein, so auch in diesem Fall. Erklärt wird die Idee der Verspätungskosten, bzw. der Cost of Delay. Gut verständlich und kompakt zusammengefasst, in nur wenigen Minuten.

Cost of Delay – An Introduction from Joshua Arnold on Vimeo.

Bemerkenswert ist, dass das Video bereits mehr als ein Jahrzehnt als ist. Was seine Erstellung damals für einen Aufwand bedeutet hat mag man sich kaum vorstellen. Heute mit KI ginge es sicher in einem Bruchteil der Zeit.

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) erstmal einfach. Man setzt ein abstraktes, mittelfristiges Ziel (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen konkreten, messbaren Ergebnissen (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Die Herausforderung, die dadurch entsteht ist aber: wie lässt sich das mit dem Alltagsgeschäft verbinden?

Die erste und naheliegende Antwort ist es, in kurzen Abständen (z.B. wöchentlich) zu überprüfen, ob Forschritt in der gewünschten Richtung stattfindet und ggf. Anpassungsmassnahmen zu beschiessen, falls die bisherigen Ergebnisse zu wünschen übriglassen. Auch hier bleibt aber offen, was genau es ist, das da begutachtet wird. Natürlich kann man sich immer wieder die OKRs selbst vorlegen, die Verbindung zum Alltagsgeschäft wäre damit aber noch immer nicht gegeben.

Ein häufig anzutreffender Ansatz zum Schliessen dieser Lücke ist, für die jeweiligen Key Results einen weiteren Work Breakdown durchzuführen und die Umsetzung der sich so ergebenden Arbeitspakete mit Hilfe eines Backlogs oder einer Roadmap zu planen.¹ Damit wird nicht nur die Umsetzungslücke geschlossen, es ist darüber hinaus möglich, die OKR-Aufwände und die sonstigen Tätigkeiten in einer gemeinsamen Planungssicht zusammenzufassen und so Redundanzen und Überplanung zu vermeiden.

Die Art der jeweiligen Arbeitspakete kann schliesslich variieren. Sie können die Bereitstellung der (Infra-)Strukturen zum Gegenstand haben, die für die Erbringung von Leistungen Voraussetzung sind, sie können aus der Fertig- und Bereitstellung von neuen Produkten, Features oder Services bestehen, sie können aber auch die Form von Business-Experimenten haben, durch die erforscht wird, auf welche Art und Weise sich Nutzergewohnheiten ändern oder Kaufanreize setzen lassen.

Wichtig bei der Definition dieses Unterbaus unterhalb der OKRs ist dabei weniger, um was für Arbeitspakete es sich genau handelt, sondern eher ob sie zur Erreichung der übergeordneten messbaren Ergebnisse, der Key Results, beitragen. Stellt sich heraus, dass sie einen Beitrag leisten, sollten sie ggf. wiederholt und intensiviert werden können, leisten sie keinen erkennbaren Beitrag muss es möglich sein, sie unbürokratisch zu variieren oder zu verwerfen. Auf keinen Fall dürfen sie zum Selbstzweck werden.

Der Vollständigkeit halber sei noch erwähnt, dass diese Art mit Objectives and Key Results zu arbeiten weder die einzige ist, noch eine die per Definition besser als andere Vorgehensweisen wäre. Es ist aber eine, mit der sich die Verbindung zwischen OKRs und Alltagsgeschäft gut herstellen lässt. Wer in diesem Bereich Verbesserungspotential sieht, kann daher einen Versuch wagen und überprüfen, wie gut dieser Ansatz für ihn funktioniert - idealerweise anhand von im voraus definierten Erfolgskriterien.

Zu den Begriffen an denen man bei der Beschäftigung mit agilen Zielsetzungs-Systemen (OKRs, Sprint Goals, etc.) früher oder später vorbeikommt, gehört auch das Loose Coupling (ins Deutsche übersetzt die lose Koppelung). Beschrieben wird das meistens damit, dass über- und untergeordnete Ziele und Massnahmen nicht zu fest miteinander verbunden sein sollen (das wäre Tight Coupling, bzw. enge Koppelung) - aber warum will man diese enge Verbindung eigentlich oft nicht?

Zum besseren Verständnis hilft es, sich Zielsetzungssysteme anzusehen, die umgekehrt gestaltet sind, in denen also Tight Coupling stattfindet. Das sieht meistens so aus, dass die untergeordneten Ziele und Massnahmen fest definierte Teilmengen der übergeordnetend sind, was zwei Folgen hat: zum einen müssen sie alle erfüllt werden um das übergeordnete Ziel zu erreichen, zum anderen sind sie so eng miteinander verbunden, dass sie sich gegenseitig beeinflussen.

Wenn das übergeordnete Ziel z.B. die Gründung einer neuen Niederlassung ist, und davon das Mieten eines Gebäudes, die Einrichtung der Arbeitsräume und die Anstellungung von geeignetem Personal abgeleitet werden, dann ist das eine enge Koppelung. Sollte eine einziges dieser Unterziele oder der dazugehörigen Massnahmen scheitern oder sich deutlich verzögern, wäre auch das übergreifende Gesamtziel in gleicher Art davon betroffen.

Drehen wir es um, wie würde hier eine lose Koppelung aussehen? Das übergreifende Ziel könnte z.B. sein, die neue Niederlassung möglichst schnell arbeitsfähig zu bekommen. Abgeleitet davon könnte man die Onboarding-Handbücher verbessern, einen Bonus für bestehende Kollegen ausloben, die sich zeitweise versetzen lassen um die neuen einzuarbeiten, oder temporär mehr Home Office erlauben. Man sieht an diesen Beispielen: wenn sie nicht gelingen sollten, wären die Folgen weit weniger tiefgreifend.

Noch einmal einfacher ist das Loose Coupling in der digitalen Produktentwicklung. Wenn z.B. das Ziel ist, die Zeit die man in einem Genehmigungsportal verbringen muss zu reduzieren, können verschiedene Entwicklungsteams völlig unterschiedliche Ideen einbringen: besseres UX-Design, schnellere Ladezeiten, hilfreiche Chatbots, etc. Alle diese Ideen tragen zum übergeordneten Ziel bei, untrennbar mit ihm verbunden sind sie aber alle nicht, und untereinander auch nicht.

Durch diese Gestaltung wird etwas möglich, was in jeder ernsthaften Bemühung agil zu Arbeiten enthalten sein sollte: autonome, selbstorganisierte Teams. Durch das Vorgeben der übergeordneten Ziels wird sichergestellt, dass sie im Sinn der Gesamtstrategie arbeiten, mit welchen untergeordneten Ziele und Massnahmen sie das machen und auf welche Art und Weise sie diese umsetzen liegt aber bei ihnen (natürlich müssen dafür bestimmte Vorbedingungen erfüllt sein, z.B. Crossfunktionalität).

Es wird aber an dieser Stelle auch offensichtlich, an welcher Stelle Loose Coupling an Grenzen stösst: dort nämlich, wo aus technischen, juristischen oder sonstigen Gründen sehr klare Vorgaben nötig sind, die dann auch genau so erfüllt werden müssen. Andererseits handelt es sich dann bei ehrlicher Betrachtung auch nicht mehr um Zielsetzungs-Systeme sondern um Anleitungs- und Kontrollsysteme. Das wäre aber nochmal ein eigenes Thema für sich.

In der Theorie klingt das Arbeiten in Sprints ganz einfach. Zu Beginn wird ein fachliches Ziel mit hohem Business Value ausgewählt und ggf. noch einmal in kleinere (Teil-)Ziele aufgeteilt, die jeweils in einen Sprint passen. Während dieses Zeitraums (meistens zwei oder drei Wochen) wird konzentriert an der Fertigstellung gearbeitet, danach wird das Ergebnis den Stakeholdern vorgestellt und mit ihnen besprochen, im Anschluss daran wird ein neuer Sprint mit einem neuen Ziel geplant.

In der Realität ist es meistens schwieriger. Zum Einen ist es meistens so, dass es auch Aufgaben gibt, die nicht den höchsten Business Value haben, die aber irgendwann erledigt werden müssen (Einspielen von Versionsupgrades, Vereinheitlichung von Farbschemata, etc). Meistens sind die auch nicht gross genug für ein eigenes Sprintziel. Zum anderen füllen Sprintziele einen Sprint fast nie völlig aus, es bleibt immer eine gewisse Restkapazität übrig.

Viele Teams gehen mit dieser Situation um indem sie etwas Naheliegendes machen: sie planen zuerst alles ein, was für die Erreichung des Sprintziels nötig ist und füllen die verbleibende Kapazität auf indem sie in der restlichen Zeit die anderen Aufgaben abarbeiten. Das ist auch grundsätzlich sinnvoll - unter der Voraussetzung, dass diese Arbeiten auch im verbleibenden Sprint abgeschlossen werden können und nicht halbfertig in den nächsten rutschen und dort Kapazität blockieren.

Ein Weg um das sicherzustellen trägt den Namen Rocks, Pebbles, Sand. Angeblich bei PayPal erfunden und durch die PayPal Mafia popularisiert funktioniert er folgendermassen: zu Beginn eines Planungstermins plant man die grossen Arbeitspakete ein, die "Felsbrocken" (Rocks). Als nächstes füllt man die verbleibende Zeit mit mittelgrossen Aufgaben, den "Steinen" (Pebbles). Die zuletzt verbleibende Zeit ist schliesslich für Kleinst-Aufgaben vorgesehen, den "Sand".

Was der Schlüssel für eine erfolgreiche Anwendung dieses Vorgehens ist, ist ein Focus auf dem Erstellen von Aufgaben, die so klein sind, dass sie die eingeplante Zeit möglichst nicht sprengen. Rocks sollten maximal so gross sein wie ein Sprint, Pebbles maximal so gross wie die im Sprint verbleibende Zeit nach dem Abzug des für die Rocks eingeplanten Aufwandes, die "Sandkörner" maximal so gross wie das, was danach noch übrig ist.

Natürlich ist damit das Risiko verbunden, dass eine derartige Kapazitätsplanung zu einer versehentlichen Überlastung führt, oder zu einer Situation in der bereits kleine zusätzliche Aufwände den verfügbaren Zeitrahmen sprengen. Es empfiehlt sich daher, auch in diesem Vorgehen einen gewissen Teil der Zeit unverplant zu lassen. Ebenfalls möglich ist es, die Aufgaben des Sand-Typs nur dann in den Sprint zu ziehen, wenn gerade kurzfristiger Leerlauf besteht.

Wenn der Mehrwert von schneller Auslieferung und schneller Reaktion auf Veränderungen beschrieben wird, gehört die Vermeidung von Verspätungskosten oder "Cost of Delay" zu den am häufigsten genannten Vorteilen. Don Reinertsen, der Erfinder des Begriffs, beschreibt ihn als die Summe, die pro Zeiteinheit (Monat, Jahr, etc.) nicht eingenommen wird, weil Produkte zu spät fertig werden. Das ist auch richtig, wie er selbst sagt aber nur verkürzt dargestellt.

Will man kalkulieren, mit welchen Verzögerungskosten man im Fall einer verspäteten Fertigstellung konfrontiert werden wird, sollte man das Konzept auffächern: gibt es unterschiedliche Arten von Kosten, und von welchen würde man betroffen sein? Die Antwort auf diese Frage wird je nach Einzelfall anders ausfallen, die folgenden Typen sind aber diejenigen, mit denen am häufigsten zu rechnen ist und die man daher in die Überlegungen einbeziehen sollte.

1. Vepasster Absatz/Gewinn pro Zeit-Einheit

Der einfachste, und von Reinertsen am häufigsten genannte Fall. Bei einem angenommenen Gewinn von zwölf Millionen pro Jahr betragen die Verspätungskosten etwa eine Million pro Monat. Dieser Schätzwert macht Abwägungen möglich. Z.B. wenn man in diesem Fall durch Investitionen von sechs Millionen ein halbes Jahr schneller am Markt wäre - wäre das den Aufwand wert (nein, eher nicht).

2. Verpasstes Saison-Geschäft

Ein etwas komplizierterer Fall. Oft ist der voraussichtliche Gewinn nicht gleich über einen längeren Zeitraum verteilt, sondern konzentriert sich auf saisonale Phasen (z.B. Weihnachten) oder nach wichtigen Veranstaltungen (z.B. Messen). Eine Verspätung zu diesen Zeiträumen hätte eine hohe Cost of Delay, eine Verspätung mit restlichen Jahr eine geringe oder gar keine.

3. Strafzahlungen wegen Verspätung

Vor allem in regulierten Branchen können auch Strafzahlungen Teil der Verspätungskosten sein. Wenn beispielsweise eine Bank ihren Compliance-Bericht nicht rechtzeitig fertigstellt, kann die Bafin eine Geldstrafe verhängen (hier ein Beispiel). Da die Höhe dieser Strafen sich ungefähr abschätzen lässt, sind auch sie als Cost of Delay bezifferbar.

4. Verpasster Abbau technischer Schulden

Die technischen Schulden sind ein ähnliches Konzept wie die Verspätungskosten. Wenn man in der IT bestimmte effizienzsteigernde Faktoren (modulare Architektur, Testabdeckung, etc.), vernachlässigt, wird man dauerhaft langsamer. Sinkt beispielsweise das Arbeitstempo durch zu viele manuelle Testprozesse um 10 Prozent, lässt sich das in Zeit und damit in Geld umrechnen.

5. Verlorenes Feature-Wettrennen

Eine Variante der ersten, einfachsten Art von Cost of Delay. Wenn ein Wettbewerber ein ähnliches Produkt entwickelt, bedeutet eine Verzögerung nicht nur, dass man später mit dem Geld verdienen beginnt, sondern, dass das auch signifikant geringer ausfällt, da ein Teil der potentiellen Kunden sich dann bereits für das Angebot der früher fertig gewordenen Konkurrenz entschieden hat.

6. Verpasste Besetzung eines neuen Marktes

Gewissermassen die Steigerung eines Feature-Wettrennens. Sowohl bezogen auf neue Käufergruppen als auch bezogen auf neuartige Produkte kann es von grossem Vorteil sein, der Erste zu sein, der diesen Markt besetzt. Alle die später in Konkurrenz zu diesen Pionieren treten, müssen mit einem deutlich höheren Aufwand für Marketing und Vertrieb rechnen, so dass auch hier Zeit gleich Geld ist.

Was bei dieser Übersicht über die verschiedenen Arten von Cost of Delay, bzw. Verzögerungskosten auffällt, ist, dass ihre Grösse nach unten immer weniger abschätzbar wird. Das liegt daran, dass auch der sich verspätende Liefergegenstand nach unten immer grösser und unkonkreter wird. Das bedeutet natürlich nicht, dass man in diesen Fällen nicht über eine Cost of Delay nachdenken sollte, man sollte aber diese Ungenauigkeit in den Schätzungen abbilden.