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.

„Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen.“ (Scrum Guide).

Historischer Rückblick

In diesem Blog-Beitrag geht es um interdisziplinäre – oder auch näher am englischen Original cross-funktionale – Teams. Bereits vor Scrum  hatten sich herausgestellt, dass diese Teams besonders erfolgreich sind bei der Entwicklung von innovativen Produkten (The New New Product Development Game (hbr.org)). Mit Scrum sind sie dann so richtig populär geworden. Als Scrum in den 1990ern entstand, waren Entwicklungsabteilungen in Form von funktionalen Teams organisiert: es gab Kästchen im Organigramm für die Entwickler:innen (damals noch nicht gegendert ) und die Tester:innen, oft noch aufgeteilt in Integrations- und Systemtest. Ich erinnere mich an meine Zeit in einem großen Konzern damals, als es gerade Mode wurde, Testabteilungen in Indien aufzubauen, um Kosten zu sparen. Weiterhin gab es Spezialfunktionen wie Systemarchitekt:innen (von bösen Zungen als „Elfenbeinturm-Architekten“ bezeichnet), Risk Manager, Integrationsmanager, Requirement Engineers… alle in ihren eigenen Abteilungen, und damit Diener ihrer jeweiligen Herren, den Abteilungsfürsten. Andere Teile des Unternehmens, die nicht direkt zur Entwicklung gehörten, wie z.B. Produktmanagement und Marketing, waren außen vor. Ein cross-funktionales Team dagegen vereinigte die Menschen, die mit ihren unterschiedlichen Expertisen zur Entstehung eines Produktes beitragen sollten, und schwor sie auf ein gemeinsames Ziel ein. Was für ein Fortschritt!

Die Vorteile liegen auf der Hand:

• Für das Team lässt sich leicht ein gemeinsames Ziel formulieren: ein Produkt mit Wert für Kunden zu erzeugen. Entwickler:innen, Tester:innen und die anderen Funktionen ziehen an einem Strang und arbeiten eng zusammen. Das steigert die Identifikation mit dem Team, die Motivation und damit auch die Leistungsbereitschaft.
• Mit ihren unterschiedlichen Skills und Sichtweisen findet das Team innovative Lösungen für komplexe Probleme.
• Übergabeformalitäten, zum Beispiel in Form von Meilensteinen wie „Ready for System Test“, können eingespart werden. So ist der Weg geebnet für ein iterativ-inkrementelles Vorgehen anstelle eines Wasserfallprozesses. Das Team ist in der Lage, schnell und agil zu agieren und seinen eigenen Prozess ständig weiterzuentwickeln.
• Um das gemeinsame Ziel zu erreichen, werden starre Rollenbeschreibungen aufgelöst. Jedes Teammitglied trägt Verantwortung zur Erreichung des Ziels. Statt der Elfenbeinturm-Architekt:innen gibt es nun Team-Mitglieder, die sich besonders gut mit Architektur von Systemen auskannten, aber auch andere Tätigkeiten übernehmen können. Team-Mitglieder lernen voneinander und entwickeln sich weiter. Das Know-How wird verbreitert, nicht nur vertieft.
• Durch die Unterschiedlichkeiten im Team entstehen Herausforderungen wie Umgang mit Konflikten und gemeinsame Entscheidungsfindung. Was auf den ersten Blick als Nachteil erscheint, ist tatsächlich ein Vorteil, wenn das Team lernt, derartige Herausforderungen gemeinsam bewältigen.

All das waren wichtige Verbesserungsschritte – die oft nur gegen den Widerstand der Abteilungsfürsten durchzusetzen waren. Allerdings waren nicht alle Probleme damit gelöst. Es existierten weiterhin Abhängigkeiten zwischen cross-funktionalen Teams, die gemeinsam an einem Produkt arbeiteten. Der Grund: Die Zuständigkeit der Teams beschränkte sich auf einzelne Komponenten des Produkts. Damit die Anteile der einzelnen Komponenten zusammenpassen, ist ein Planungsschritt notwendig, der diese Anteile identifiziert. Zur Erzeugung des Produktes müssen die Beiträge der Komponenten zusammengebaut werden. Es gibt also Analyse, Entwicklung, Integration und Test mit den entsprechenden Verantwortlichkeiten – ist das wirklich der große Fortschritt im Vergleich zum klassischen Wasserfallprozess?

Feature Teams – ein weiterer Schritt zur Business Agility

Feature Teams sind cross-funktionale Teams, die end-to-end Verantwortung für komplette kunden-orientierte Features übernehmen und so eigenständig Wert für Kunden erzeugen können. Hört sich gut an (s. Feature Teams – Large Scale Scrum (LeSS)) – in der Realität ist es ein sehr anspruchsvolles Unterfangen, Feature Teams aufzustellen. Als Voraussetzung sind hervorragende technische Fähigkeiten nötig wie kontinuierlicher Integration, Test und Auslieferung, die leider in vielen Organisationen nicht vorhanden sind. Der Schritt von Komponenten- zu Feature Teams erfordert eine Umorganisation mit vielen Reibungsverlusten. Ich habe als Coach erlebt, dass Organisationen mehrere Versuche und Experimente gebraucht haben, bevor sie genügend Erfahrung beisammen hatten, sich als Feature Teams aufzustellen (s. z.B. German Big Insurance – Large Scale Scrum (LeSS)). Und selbst wenn dies in der Software-/Produktentwicklung gelingt, besteht ein end-to-end-Prozess aus weiteren Aktivitäten, angefangen mit dem Portfolio-Management über Budgetfreigabe bis zum Marketing, die man in großen Organisationen nicht auch noch in den Feature Teams unterbringt.

Also: cross-funktionale, end-to-end Teams sind ein wichtiger Baustein für agile Unternehmen. Um wirkliche Business Agility zu erreichen und damit in der Lage zu sein, als gesamte Organisation schnell zu reagieren und zu liefern, braucht es eine Sicht auf die Abhängigkeiten und Interaktionen zwischen den Teams und die dort entstehenden Wartezeiten. Mit einem Blick auf das gesamte System und seine Wertschöpfungsketten sollte man zunächst herausfinden, wo es kritische Abhängigkeiten gibt und wirklich hakt, um dann an diesen Stellen gezielte Verbesserungen vornehmen zu können.

Einsatzmöglichkeiten für cross-funktionale Teams

Agilität ist als Denkansatz längst über die Software- bzw. Produktentwicklung hinausgewachsen – und damit auch die cross-funktionalen Teams. Ich habe solche Teams in allen möglichen Bereichen unterstützen dürfen: von einem Team, das ein IT-Sicherheitskonzept zum Schutz gegen Hackerangriffe entwickeln sollte, bis hin zu einem Team, das Governance-Richtlinien zur Sicherstellung von Nachhaltigkeitsaspekten erstellen sollte. Mitglieder in diesen Teams waren Personen aus der Unternehmenskommunikation und der Organisationsentwicklung, Jurist:innen, Change Manager, Vertreter:innen aus den einzelnen Regionen… mit den nötigen Entscheidungsbefugnissen und Entlastung von operativen Tätigkeiten ausgestattet, können solche Teams sehr effektiv arbeiten. 

Inter- und extra-dependent Teams

Sind die cross-funktionalen Teams – zumindest als Grundbaustein – also ein Allheilmittel, wenn es um die effektive Lösung von komplexen Problemen geht?

Denken wir zurück an die so oft geschmähten „Silos“ (dieser Begriff wird heute von den meisten Agilisten mit einem unverkennbar abwertenden Gesichtsausdruck verwendet). Die Leistung der „Silos“ besteht in der Weiterentwicklung einer bestimmten Expertise, die allen Mitgliedern des „Silos“ gemeinsam war. Also zum Beispiel Test-Kompetenz. Damit sorgte das „Silo“ dafür, dass Fachwissen in einer Organisation entsteht und erhalten bleibt. Die Motivation dahinter ist die Erhöhung von Qualität und Effizienz – was in der agilen Welt heute als ewig gestrige Denkweise und kontraproduktiv bei der Lösung komplexer Probleme verschrien ist. Erfolgreiche Organisationen brauchen aber beides: agiles Vorgehen bei der Nutzung von neuen Chancen UND effizientes Vorgehen bei etablierten Prozessen mit wenig Unsicherheit. Durch die gemeinsame Expertise schaffen die „Silos“ ein Zusammengehörigkeitsgefühl, das langfristiger sein kann als die Entwicklung eines Produktes. Wo bleibt dieser Aspekt bei den cross-funktionalen Teams? Na klar, dafür gibt es die „Communities of Practise (CoP)“ – ein team-übergreifender Zusammenschluss von Personen einer bestimmten Fachrichtung wie Test oder Architektur. Im Gegensatz zu den „Silos“ aber eher informell und damit im Zweifelsfall weniger wichtig als die Arbeit im „eigentlichen“, cross-funktionalen Produktteam.

Dieser Zusammenhang ist mir deutlich geworden bei der Lektüre von „Extra-Dependent Teams“ (David Kesby). David argumentiert, dass die gängige Team-Lehre zwischen „richtigen“ Teams und „work groups“ unterscheidet. Die Team-Lehre suggeriert, dass jede Gruppe sich am besten zu einem „richtigen“ Team entwickeln sollte, weil sie nur dadurch „high performing“ werden kann. Dazu sind – so lehrt uns die Lehre – bestimmte Attribute notwendig, wie ein gemeinsames Ziel, gemeinsame Verantwortung und Interdisziplinarität. Dabei wird verkannt, dass die „work group“ ein hervorragendes Modell zum Beispiel für CoPs ist. Um zu vermeiden, dass „work groups“ als bloßes Übergangsstadium zum „richtigen“ Team und damit als minderwertig betrachtet werden, nennt David sie „extra-dependent“ Teams – im Gegensatz zu den „inter-dependent Teams“, unseren Produktteams. Die Mitglieder der extra-dependent Teams arbeiten nicht ständig zusammen, sondern hauptamtlich als Mitglieder von inter-dependent Teams. Sie erfüllen aber eine wichtige Aufgabe, indem sie gemeinsam lernen, strategisch wichtiges Wissen erzeugen und gute Praktiken, Richtlinien, Tools… für die Organisation bereitstellen. Im Gegensatz zu CoPs, die eher informell sind, sind diese extra-dependent Teams in der Regel eine Organisationseinheit mit einer gemeinsamen Führungskraft.

Ein anschauliches Beispiel für ein extra-dependent Team ist die Schwangerschaftsgruppe zur Geburtsvorbereitung. Das inter-dependent Team ist die einzelne Familie. Die Familie hat damit ein gemeinsames Ziel: ein gesundes Baby auf die Welt zu bringen. Die Geburtsvorbereitungsgruppe hat kein gemeinsames, sondern ein identisches Ziel. Übertragen auf die agile Welt sind dies Einheiten, „Silos“, von Tester:innen, Designer:innen, Produkt-Manager:innen, Scrum Master:innen…

Ein weiteres Beispiel sind wir – improuv. Wir arbeiten als Coaches und Berater:innen bei unseren Kunden als Mitglieder von inter-dependent Teams. Wir bilden aber auch gemeinsam mit unseren improuv-Kolleg:innen ein extra-dependent Team: wir entwickeln neuen Ideen, führen kollegiale Fallberatungen und tauschen unsere Erfahrungen aus. Unser identisches Ziel ist es,  gemeinsam zu lernen und Spaß dabei zu haben – und improuv langfristig erfolgreich zu machen. 

Je größer die Organisation ist, desto eher werden bestimmte Funktionen zentral zusammengefasst: HR, Legal, Finance, Marketing, Sales, Procurement… sind Beispiele dafür. Um Kundenorientierung und damit Business Agility zu erreichen, sollte das Geschehen jedoch nicht von diesen Zentraleinheiten bestimmt werden, sondern vom Kunden, bzw. von kundenorientierten Teams. Die Aufgabe der Zentraleinheiten ist es, diese zu unterstützen. Ein Business Partner aus HR, der für einen bestimmten Bereich zuständig ist, ist „interdependent“ Mitglied dieses Bereichs und gleichzeitig „extradependent“ Mitglied seiner HR-Einheit.

Extra-dependent Teams sind die Realität in Organisationen. Nach Untersuchungen von David in drei Organisationen machen sie zwischen 43 un 69% aller Teams aus! Wir sollten also vermeiden, alle Teams über einen Kamm zu scheren und extra-dependent Teams in das Raster eines inter-dependent Teams zu pressen. Das führt nur zu Frustration und nicht zu der erwarteten Verbesserung der Performance. 

Fazit: Cross-funktionale Teams sind super – aber bitte nicht als Dogma. Die Arbeit an Produkten ist eben nur ein Teil einer agilen Organisation. Ein Team ist mehr als die Summe seiner Mitglieder – und eine Organisation ist mehr als die Summe seiner Teams.

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.