Nach welchen Kriterien ordnet ihr euer Product Backlog? Nach Abhängigkeiten zwischen Produkt-Komponenten oder Teams? Nach Verfügbarkeit von bestimmten Experten? Nach der Lautstärke von Stakeholder-Stimmen? Oder lasst ihr wirtschaftliche Erwägungen in die Ordnung einfließen?

Als Product Owner:in seid ihr – laut Scrum Guide – nicht nur für ein effektives Backlog Management zuständig, sondern auch für die Maximierung des Werts des Produkts. Das bedeutet aus ökonomischer Sicht: die Maximierung des Profits, den ihr mit dem Produkt generieren könnt. Dazu hat sich Don Reinertsen in seinem Buch “The Principles of Product Development Flow” viele Gedanken gemacht. Ich möchte ein paar wesentliche Gesichtspunkte daraus extrahieren, die beim Product Backlog Management helfen, gute ökonomische Entscheidungen zu treffen. Genauer gesagt soll es darum gehen, das Product Backlog nach ökonomischen Kriterien zu ordnen, seine Größe und den Anteil für Releases festzulegen. 

Entscheidungen nach ökonomischen Auswirkungen treffen

In der Praxis werden ganz unterschiedliche Ziele für die Produktentwicklung angegeben: Innovation erzeugen, Qualität verbessern, einen Plan einhalten, Verschwendung reduzieren… Sehr häufig hat die Product Owner:in sich mit Zielkonflikten herumzuschlagen, zum Beispiel: ist es besser, das Produkt jetzt zu releasen, oder sollten erst die bekannten Fehler beseitigt werden? Die einhellige Meinung in der agilen Community ist: Technische Schulden sind des Teufels und sollten auf jeden Fall vermieden werden. Aber ist diese Meinung immer ökonomisch gerechtfertigt? Ein weiteres Beispiel: Sollte das Produkt mit einem Minimum an Features auf den Markt, um frühes Feedback zu bekommen, oder sollten lieber noch ein paar weitere Features eingebaut werden, um die Chance auf begeisterte Kunden zu erhöhen? Wäre es nicht großartig, wenn wir diese Möglichkeiten anhand einer Größe vergleichen könnten, die den Einfluss auf den Profit während des gesamten Produkt-Lebenszyklus ausdrückt? Schauen wir uns das an dem ersten Beispiel von oben an:

Option A: Wieviel kostet es, das Release zu verschieben, bis alle Fehler beseitigt sind? Die CoD ist der in der Verzögerungszeit entgangene Gewinn. Sie ist in der Regel nicht konstant über die Zeit. Die Konkurrenz schläft nicht… vielleicht verpassen wir durch die Verschiebung ein wichtiges Marktfenster, und die Gewinnerwartung geht auf Null. Währenddessen steigen die Entwicklungskosten weiter an. Die folgende Abbildung aus dem Kanban Maturity Model der Kanban University zeigt verschiedene mögliche Zeitverläufe.

Die Verzögerung hat noch einen weiteren Nachteil: Da wir ein späteres Feedback vom Markt erhalten, leben wir länger mit der Unsicherheit, dass unser Produkt nicht gekauft wird. 

Option B: Wieviel kostet es, die Fehlerbeseitigung zu verschieben, bis das Produkt am Markt ist? Wir erzeugen technische Schulden. Die Beseitigung eines Fehlers wird um so teurer, je weiter wir sie in die Zukunft verschieben, da es im Produkt Seiteneffekte gibt und der Testaufwand steigt. Außerdem besteht das Risiko, Kunden durch schlechte Qualität zu verärgern und dadurch einen Imageverlust zu erleiden. 

Diese beiden Optionen mit konkreten Zahlen zu versehen, ist schwierig und abhängig vom jeweiligen Kontext, aber allein die Überlegungen dahinter sind sehr aufschlussreich. Sie helfen, Entscheidungen rational abzusichern und sich nicht (nur) auf sein Bauchgefühl zu verlassen. Solche Entscheidungen sind in der Regel stabiler und lassen sich besser begründen – auch wenn der Stakeholder mit der lauten Stimme anruft. Also: Quantifizieren wenn möglich, aber nicht um jeden Preis. 

Verzögerungen kosten also Geld. Sie führen zu

• erhöhtem Risiko durch veränderte Markt-/Kundensituation
• verspätetem Feedback und dadurch erhöhten Kosten für “falsche” Entwicklungen und verminderter Qualität
• erhöhten Prozesskosten und Overhead
• abnehmender Motivation bei den Entwicklungsteams

Das Product Backlog als Warteschlange

Wie kommen diese Verzögerungen überhaupt zu Stande? Die Antwort ist: durch Wartezeiten. Wie bitte? Wir sind doch alle ständig am Rotieren und füllen Wartezeiten sofort mit neuen Aktivitäten. Genau da liegt das Problem: wir betrachten den einzelnen Menschen, oder das einzelne Team (allgemein: einen Service), und sehen deren Auslastung. Was wir nicht im Blick haben, ist die Arbeit, die von einem Service zum anderen weitergereicht wird. Vor ausgelasteten Services entstehen Warteschlangen, die das Weiterreichen zur nächsten Station verzögern. Am einfachsten können wir uns das an einer Schlange im Supermarkt veranschaulichen. Sobald der Service (in diesem Fall die Kassierer:in) nicht mehr nachkommt mit Kassieren, bildet sich eine Schlange. Wenn wir erst an der Wursttheke, dann an der Brottheke und dann noch einmal an der Kasse in der Schlange stehen müssen, verzögert sich die Gesamtdurchlaufzeit um so mehr.

Warteschlangen sind die Hauptursache für Verzögerungen und damit für Verschwendung in der Produktentwicklung. Um das zu verstehen, helfen zwei Erkenntnisse aus der Warteschlangentheorie:

• Die Länge von Warteschlangen steigt massiv mit der Auslastung. Unsere intuitive Annahme, dass hohe Auslastung zu schneller Abarbeitung führt, ist verkehrt. Das Gegenteil ist der Fall. Dies zeigt die folgende Abbildung.
• Im langfristigen Durchschnitt gilt: Wartezeit = Länge der Warteschlange / Abarbeitungszeit, wenn das System stabil ist, also genauso viel neu rein kommt, wie hinten abgearbeitet wird (Little’s Gesetz).
• Warteschlangen entstehen schneller als sie sich wieder abbauen. Das weiß jeder aus Erfahrung, der schon einmal einen Verkehrsstau erlebt hat, lässt sich aber auch mathematisch zeigen.

Das Product Backlog ist eine Warteschlange, in dem Product Backlog Items (PBIs) auf ihre Abarbeitung warten. Jeder Service, der in der Produktentwicklung eine Rolle spielt, hat eine eigene Warteschlange. Das können unterschiedliche Teams sein, die gemeinsam an einem Produkt arbeiten, aber auch Einheiten außerhalb der Entwicklung, wie z.B. Marketing oder die Rechtsabteilung. Wir sollten also unsere Aufmerksamkeit weg von der Auslastung der einzelnen Services hin zu den Arbeitsaufträgen lenken. Solche gekoppelten Warteschlangensysteme sind, wenn es auch Rückkopplungen gibt, chaotische Systeme im mathematischen Sinne, die nicht vorhersehbares Verhalten zeigen – und sich mit traditionellen Planungen nicht in den Griff bekommen lassen. 

Product Backlog Items ökonomisch ordnen

Na prima, nachdem wir dieses Problem verstanden haben, finden wir eine Lösung: wir verringern die Auslastung der Services bzw. erhöhen deren Kapazität. Das macht der Supermarkt ja auch, wenn bei langen Schlangen zusätzliche Kassen geöffnet werden. Leider ist das nicht umsonst zu haben: wir brauchen zusätzliches Personal oder Schulungen, durch die das Personal an unterschiedlichen Stellen eingesetzt werden kann. Ist das ökonomisch gerechtfertigt? Dazu sollten wir statt der Größe die Kosten der Warteschlangen betrachten. Diese können wir durch die Reihenfolge der Einträge in der Warteschlange beeinflussen. Product Backlog Items (PBIs) mit großer CoD kommen ganz nach oben. Als weitere Regel kommt hinzu: kurze Aufträge vor langen Aufträgen. Kurze Aufträge blockieren den Service weniger lang und führen schneller dazu, dass die Warteschlange sich wieder abbaut. Die Abbildung veranschaulicht zwei Fälle: im ersten Fall ist der erste Job der mit hoher CoD und niedriger Dauer. Im zweiten Fall ist es umgekehrt. Der Unterschied ist deutlich zu erkennen: die hohen CoDs akkumulieren sich im zweiten Fall über einen längeren Zeitraum.

Arbeiten in kleinen Stapeln

Eine weitere Möglichkeit, Wartezeiten zu reduzieren, ist die Verwendung von geringen Stapelgrößen (Batch Size). Damit ist die Anzahl von zusammengehörigen Arbeitseinheiten gemeint, also z.B. die Tasks in einem Sprint, oder die Features (und deren Tasks) in einem Release. Die bisherigen Betrachtungen gingen davon aus, dass Arbeit vereinzelt und zeitlich gleichmäßig verteilt beim Service ankommt. Das entspricht z.B. einem Team, dass eine bestimmte Zahl von kleineren Bugs mit mittlerer Auslastung erledigen kann. Die Realität ist aber nicht so. Arbeitsaufträge kommen zufällig, mit variablen Zeitabständen und variabler Größe und in Stapeln. Wie bei einem Restaurant, wenn ein Bus mit 40 hungrigen Touristen vorfährt. Plötzlich steigt die Warteschlange und damit die Wartezeit rapide an. Das Personal gerät in Stress, arbeitet an der Auslastungsgrenze, wodurch sich der Effekt noch verstärkt. Die Stapelgrößen sind oft nicht offensichtlich und eine Frage der “Flughöhe”: Für ein Produktentwicklungs-Team versteckt sich hinter einem großen Requirement oder Feature ein Stapel von kleineren Arbeitsaufträgen.

Eine Möglichkeit, Stapelgrößen und die Länge von Warteschlangen zu begrenzen, sind Work In Progress (WIP) Limits. WIP ist die Anzahl der Arbeitseinheiten, die noch nicht fertiggestellt sind. zum Beispiel durch ungetesteter Code oder halb-umgesetzte Anforderungen. Wir können WIP kontrollieren, indem wir die Annahme von weiteren Aufträgen verweigern, wenn das WIP-Limit erreicht ist. Ein extremer Ansatz ist, die neuen Aufträge komplett zu verwerfen. Eine andere Möglichkeit ist, sie zu blockieren. Sie bleiben dann “weiter oben” in der Prozesskette hängen, wo sie weniger Kosten verursachen. Zum Beispiel ist es oft besser, neue Opportunities in einer Warteschlange zu halten und nicht in die Produktentwicklung eintreten zu lassen. Denn dort erhöhen sie die Auslastung, verursachen Kosten und Overhead. 

Don Reinertsen zeigt an einem Beispiel, dass bereits moderate WIP-Begrenzungen einen großen ökonomischen Effekt haben können: bei einem WIP-Limit, das doppelt so groß ist wie der durchschnittliche WIP ohne Limit, entstehen Kosteneinsparungen durch die verminderte CoD, die fast 10mal so groß sind wie die zusätzlichen Kosten durch zurückgewiesene Aufträge. Natürlich sollten bei hohem WIP besonders solche Aufträge abgewiesen werden, die eine geringe Werterzeugung bieten.

In einer iterativ-inkrementellen Entwicklung helfen die Sprints, Stapelgrößen klein zu halten. Kanban-Systeme, die den Namen verdienen, sind per Definition WIP-limitiert. Es geht aber auch um Releases – in Sinne von kleinen Stapelgrößen und schnellem Feedback – möglichst häufig erfolgen sollten. Bei unserer ökonomischen Betrachtung stehen diesem Vorteil die Transaktions- oder Overhead-Kosten gegenüber, die mit einem Release verbunden sind, z.B. Systemtests, manuelle Tests, Dokumentation, Freigabe, Auslieferung. Eine Investition in gute Infrastruktur zur Verringerung der Transaktionskosten, zum Beispiel durch Automatisierung, kann sich dann schnell auszahlen .

Product Backlogs sind überall

Wie oben schon erwähnt, besteht eine Produktentwicklung nicht nur aus einem Product Backlog bzw. einer Warteschlange, sondern aus ganz vielen. Das  klassische Projektmanagement, die Kritische-Pfad-Analyse und die Wertstromanalyse gehen davon aus, dass die Produktentwicklung eine lineare Sequenz von Schritten ist. Das muss aber nicht so sein. Bei manchen Aufträgen wird mehrfach die Unterstützung des Marketing-Teams benötigt. Bei anderen ist vor allem ein Backend-Team involviert. Bei wieder anderen liegt der Engpass bei den Nutzern, die den Akzeptanztest durchführen sollen. Statt einer linearen Abfolge haben wir ein Netzwerk von Funktionen und können von der Funktionsweise des Internets lernen: Das Produkt wird in Pakete heruntergebrochen, die durch dieses Netzwerk wandern, so wie es für das jeweilige Paket sinnvoll ist, und wie es der jeweilige Belastungs- und Warteschlangenzustand der Stationen erlaubt. 

Noch eine Erweiterung der bisherigen Erkenntnisse. Wir können sie auf ein einzelnes Product Backlog anwenden, aber auch auf einer höheren Ebene auf ein ganzes  Programm oder Portfolio von Projekten. Ein Riesen-Problem ist häufig, dass Mitarbeiter oder ganze Teams nicht nur in einem Projekt mitarbeiten, sondern in mehreren gleichzeitig. Es gibt keine WIP-Limits. Kein Wunder, dass die Fertigstellung von Projekten oft so lange dauert. Leider gibt es oft Hemmungen, einmal gestartete Projekte einzustellen. Statt dessen werden ihnen die Mitarbeiter:innen entzogen, so dass sie weder tot noch lebendig sind – Zombie-Projekte. 

Die folgende Darstellung veranschaulicht dies für vier Projekte. Im ersten Fall laufen alle parallel. Im zweiten Fall werden zunächst Projekt 1 und 2 fertiggestellt, bevor 3 und 4 gestartet werden. Davon profitieren nicht nur Projekt 1 und 2 (geringere CoD), sondern auch 3 und 4: sie können von den Ergebnissen von 1 und 2 lernen, und sie vermeiden Overhead durch die geringere Laufzeit.

Zum Abschluss noch zwei persönliche Bemerkungen zu den Arbeiten von Don Reinertsen: ich finde den ökonimischen Blickwinkel wichtig und notwendig für eine wirtschaftlich denkenden Product:Ownerin. Das Buch ist jedoch nicht gerade leichte Kost, und mir fällt es schwer, seine quantitativen und statistischen Analysen nachzuvollziehen und auf eigene Beispiele zu übertragen. Weiterhin vermisse ich Aspekte, die über die Ökonomie der Produktentwicklung hinausgehen, zum Beispiel Nachhaltigkeitsaspekte. Es ist wichtig zu erkennen, dass Überlastung von Mitarbeitern zu CoD führt, aber noch wichtiger ist es sich zu überlegen, was das für ihre Gesundheit bedeutet. Folgekosten für Umwelt oder Gesellschaft sollten auch in eine ökonomische Betrachtung einbezogen werden. Die Cost of Delay einer solchen Maßnahme ist jetzt schon riesig und wird immer größer.