„Wir müssen schneller werden.“ Diesen Satz hören Entwicklungsteams in fast jeder Organisation irgendwann.
Meist folgt daraus der Reflex, Prozesse zu beschleunigen, mehr parallel zu arbeiten oder zusätzliche Kapazität aufzubauen. Und oft ändert sich dadurch wenig. Denn hinter der Forderung nach Geschwindigkeit steckt eigentlich eine Aussage über die Lieferfähigkeit der Organisation, nur eben eine verkürzte. Und was Lieferfähigkeit tatsächlich umfasst, bleibt dabei unausgesprochen.
Der Begriff „Lieferfähigkeit“ fungiert in vielen Organisationen als eine Art Container, in den jeder hineinprojiziert, was gerade am dringendsten erscheint. Für die Geschäftsführung bedeutet er Termintreue, für das Produktmanagement bedeutet er Feature-Geschwindigkeit, für das Engineering-Team bedeutet er weniger Störungen im Arbeitsfluss. Alle verwenden dasselbe Wort, meinen aber unterschiedliche Dinge. Solange das nicht sichtbar wird, reden alle aneinander vorbei, auch und gerade bei der Auswahl von Kennzahlen.
Im ersten Teil dieser Serie ging es darum, für wen und warum überhaupt gemessen werden sollte. Die Stakeholder-Analyse hat gezeigt, dass verschiedene Zielgruppen unterschiedliche Informationen brauchen und die Motive hinter einer Messung über deren Nutzen oder Schaden entscheiden. Das war das Fundament. Was noch fehlt, ist ein gemeinsames Verständnis davon, was Lieferfähigkeit eigentlich umfasst, bevor konkrete Metriken ins Spiel kommen. Denn wer den Begriff auf eine einzige Dimension reduziert, optimiert blind und verschlechtert dabei häufig genau das, was eigentlich verbessert werden sollte.
Organisationen, die ihre Lieferfähigkeit verbessern wollen, greifen typischerweise zur nächstliegenden Stellschraube: Geschwindigkeit. Das klingt intuitiv richtig und führt in der Praxis dennoch regelmäßig in eine Sackgasse.
Ein Muster, das in wachsenden Technologieunternehmen immer wieder auftaucht: Das Management stellt fest, dass Features zu lange brauchen. Als Reaktion wird die Durchlaufzeit zum zentralen KPI erklärt. Teams beginnen, darauf zu optimieren, und tatsächlich sinken die Durchlaufzeiten einzelner Aufgaben. Gleichzeitig beschweren sich Stakeholder weiterhin über verpasste Termine, weil die Streuung der Lieferzeiten enorm ist. Manche Features sind in drei Tagen fertig, andere brauchen sechs Wochen. Die durchschnittliche Geschwindigkeit hat sich verbessert, die Planbarkeit hingegen nicht. Und planbar zu liefern war eigentlich das, was die Geschäftsführung mit „schneller“ gemeint hatte.
Dieses Muster ist kein Einzelfall, sondern die Regel, wenn Lieferfähigkeit eindimensional verstanden wird. Die Ökonomie kennt ein Analogon: Wer den Wohlstand eines Landes ausschließlich über das Bruttoinlandsprodukt misst, übersieht Verteilung, Nachhaltigkeit und Lebensqualität. Das BIP kann steigen, während sich die Lebenssituation großer Bevölkerungsteile verschlechtert. Bei der Lieferfähigkeit verhält es sich ähnlich. Eine einzelne Kennzahl kann steigen, während die tatsächliche Fähigkeit, Wert zu liefern, stagniert oder sich sogar verschlechtert.
Was es braucht, ist ein Modell, das die verschiedenen Facetten von Lieferfähigkeit sichtbar macht und deren Zusammenspiel beschreibt. Nicht um ein weiteres Framework zu propagieren, sondern um eine gemeinsame Sprache zu schaffen, mit der Stakeholder, Entwicklungsteams und Führungskräfte über dasselbe reden, wenn sie „Lieferfähigkeit“ sagen.
Lieferfähigkeit in der Softwareentwicklung lässt sich auf drei Kerndimensionen zurückführen: Geschwindigkeit, Durchsatz und Vorhersagbarkeit. Jede dieser Dimensionen beantwortet eine andere Frage, adressiert andere Stakeholder-Bedürfnisse und erfordert andere Hebel zur Verbesserung.
Geschwindigkeit ist die Dimension, an die zuerst gedacht wird, und die am häufigsten missverstanden wird. In vielen Organisationen wird Geschwindigkeit mit „schneller arbeiten“ gleichgesetzt, also mit höherem Tempo der einzelnen Personen. Das greift fundamental zu kurz.
Die relevante Frage ist nicht, wie schnell jemand an einer Aufgabe arbeitet, sondern wie lange eine Aufgabe insgesamt braucht, um das gesamte System zu durchlaufen. Und hier zeigt sich ein Muster, das Niklas Modig und Pär Åhlström in „This is Lean“ als Effizienzparadoxon beschrieben haben: In den meisten Organisationen verbringt eine Aufgabe den Großteil ihrer Durchlaufzeit nicht in aktiver Bearbeitung, sondern in einem Wartezustand. Warten auf Review, warten auf Freigabe, warten auf eine Testumgebung, warten auf Klärung einer Abhängigkeit. Die sogenannte Flow-Effizienz, also das Verhältnis von aktiver Bearbeitungszeit zu Gesamtdurchlaufzeit, liegt in vielen Softwareorganisationen bei Werten, die selbst erfahrene Führungskräfte überraschen. Wenn ein Feature zehn Tage vom Start bis zur Auslieferung braucht, aber nur an zwei davon tatsächlich jemand daran arbeitet, dann liegt das Geschwindigkeitsproblem nicht bei den Menschen, sondern im Prozess.
Das bedeutet: Geschwindigkeit verbessern heißt in der Regel nicht „schneller arbeiten“, sondern Wartezeiten reduzieren. Die Ursachen dafür liegen selten im einzelnen Team, sondern in Übergaben zwischen Teams, in Abhängigkeiten, in Genehmigungsprozessen und in zu viel gleichzeitig laufender Arbeit. Wer das verstanden hat, sucht nicht nach fleißigeren Entwicklern, sondern nach systemischen Engpässen. Der Artikel über die Kosten hoher Auslastung geht auf die Mechanik dahinter im Detail ein.
Wichtig ist auch die Erkenntnis, dass schneller nicht automatisch besser ist. Geschwindigkeit auf Kosten von Qualität erzeugt kurzfristige Verbesserungen und langfristige Probleme. Geschwindigkeit ohne Vorhersagbarkeit macht Planung unmöglich. Und Geschwindigkeit als isolierte Zielgröße erzeugt exakt jene Fehlanreize, vor denen der erste Teil dieser Serie warnt.
Durchsatz beantwortet eine andere Frage als Geschwindigkeit, obwohl beide häufig verwechselt werden. Geschwindigkeit beschreibt, wie lange eine einzelne Aufgabe braucht. Durchsatz beschreibt, wie viele Aufgaben in einem bestimmten Zeitraum abgeschlossen werden. Ein System kann durchaus schnelle Durchlaufzeiten aufweisen und trotzdem wenig liefern, etwa wenn es an Kapazität fehlt oder Engpässe den Fluss begrenzen. Umgekehrt kann ein System viel liefern, ohne dass einzelne Aufgaben besonders schnell fertig werden.
Die naheliegende Reaktion auf zu geringen Durchsatz ist, mehr gleichzeitig zu tun: mehr Features parallel zu starten, mehr Aufgaben auf die Boards zu packen, mehr Personen gleichzeitig an verschiedenen Dingen arbeiten zu lassen. Donald Reinertsen hat in „The Principles of Product Development Flow“ ausführlich beschrieben, warum diese Intuition trügt. Mehr parallele Arbeit erhöht nicht den Durchsatz, sondern die Menge angefangener, aber nicht fertiggestellter Arbeit. Die Folge sind längere Wartezeiten, mehr Kontextwechsel und paradoxerweise weniger abgeschlossene Ergebnisse.
Dieser Zusammenhang ist eine der am besten dokumentierten und gleichzeitig am hartnäckigsten ignorierten Erkenntnisse in der Softwareentwicklung. Wer sich fragt, warum das Thema Multitasking in diesem Kontext so zentral ist, findet in der Betrachtung der Kosten von Aufgabenwechseln eine detaillierte Aufschlüsselung. Der Schlüssel zu höherem Durchsatz liegt nicht darin, mehr anzufangen, sondern darin, mehr fertigzustellen. Und das gelingt am besten, indem die Menge gleichzeitig laufender Arbeit bewusst begrenzt wird.
Dabei spielt auch die Art der Arbeit eine Rolle. Nicht jede abgeschlossene Aufgabe erzeugt den gleichen Wert, und nicht jeder Engpass lässt sich durch mehr Kapazität lösen. Wenn ein Team hauptsächlich damit beschäftigt ist, zwischen verschiedenen Kontexten zu wechseln, weil zu viele Vorhaben gleichzeitig laufen, dann sinkt der effektive Durchsatz selbst bei gleichbleibender Arbeitszeit. Die Kosten entstehen nicht durch Untätigkeit, sondern durch den kognitiven Overhead, den ständige Wechsel zwischen Themen, Codebasen und Anforderungen erzeugen. Verschwendung in der Softwareentwicklung tritt selten in offensichtlicher Form auf, sondern versteckt sich genau in solchen Strukturen.
Ein weiterer Aspekt, der beim Durchsatz oft übersehen wird: Es zählt nicht nur die Menge, sondern auch, was geliefert wird. Zwanzig abgeschlossene Aufgaben pro Woche klingen beeindruckend, sagen aber nichts über den erzeugten Wert aus. Wenn fünfzehn davon Bugfixes sind, die durch mangelnde Qualität entstanden sind, dann ist der tatsächliche Wertdurchsatz deutlich geringer. Die Unterscheidung zwischen Output, also der Menge an Ergebnissen, und Outcome, also dem tatsächlich erzeugten Nutzen, ist für die Interpretation von Durchsatz entscheidend.
Vorhersagbarkeit ist die am meisten unterschätzte Dimension von Lieferfähigkeit und gleichzeitig die, die für Entscheidungsträger den höchsten Wert hat.
Ein Softwareteam, das im Durchschnitt Features in zehn Tagen ausliefert, klingt zunächst solide. Doch wenn die tatsächlichen Lieferzeiten zwischen drei und dreißig Tagen schwanken, ist der Durchschnitt bedeutungslos für jede Art von Planung. Kein CTO kann mit dieser Bandbreite gegenüber der Geschäftsführung seriöse Roadmap-Commitments eingehen. Kein Product Owner kann verlässlich kommunizieren, wann ein Kunde mit einem Feature rechnen darf. Der Durchschnitt verschleiert, was die Streuung offenlegt: fehlende Verlässlichkeit.
Genau hier liegt ein Missverständnis, das in vielen Organisationen unerkannt bleibt. Wenn die Geschäftsführung sagt „Wir müssen schneller liefern“, meint sie oft in Wirklichkeit „Wir müssen verlässlicher liefern“. Denn das eigentliche Problem ist selten, dass Dinge zu lange dauern. Das eigentliche Problem ist, dass niemand sagen kann, wie lange sie dauern werden. Die Fähigkeit, realistische Prognosen abzugeben und diese einzuhalten, ist für die strategische Steuerung eines Unternehmens wertvoller als eine Verbesserung der Durchschnittsgeschwindigkeit um zwanzig Prozent.
Forsgren, Humble und Kim haben in ihrer Forschung zu High-Performance-Organisationen, veröffentlicht in „Accelerate“, ein Ergebnis dokumentiert, das auf den ersten Blick kontraintuitiv wirkt: Die leistungsstärksten Organisationen sind gleichzeitig schnell und stabil. Es gibt keinen Trade-off zwischen Geschwindigkeit und Verlässlichkeit, zumindest nicht bei Organisationen, die ihre Prozesse systematisch verbessern. Im Gegenteil, die Maßnahmen, die Vorhersagbarkeit erhöhen, etwa die Reduktion von Work-in-Progress und die Beseitigung systemischer Engpässe, verbessern häufig auch Geschwindigkeit und Durchsatz als Nebeneffekt.
Vorhersagbarkeit zu verbessern bedeutet, die Streuung der Durchlaufzeiten zu reduzieren. Nicht den Mittelwert nach unten zu drücken, sondern die Ausreißer nach oben zu verstehen und zu beseitigen. Die Werkzeuge dafür, von Perzentilwerten über Verteilungsanalysen bis zu Monte-Carlo-Simulationen (LINK), sind ein umfangreiches Thema für sich. Entscheidend ist zunächst die Erkenntnis, dass Vorhersagbarkeit eine eigenständige Dimension ist und nicht automatisch aus hoher Geschwindigkeit folgt. Ein Team kann im Durchschnitt schnell sein und trotzdem unvorhersagbar liefern, wenn die Variabilität im System hoch ist. Und umgekehrt kann ein Team mit moderaten Durchlaufzeiten hochgradig vorhersagbar sein, wenn die Streuung gering ist. Für Stakeholder ist das zweite Szenario in vielen Fällen das wertvollere.
Bei einer oberflächlichen Betrachtung könnte Qualität als vierte Dimension neben Geschwindigkeit, Durchsatz und Vorhersagbarkeit stehen. Doch diese Einordnung wäre irreführend, weil Qualität eine andere Rolle im System spielt. Qualität ist keine parallele Stellschraube, an der man unabhängig von den anderen dreht. Sie ist der Rahmen, der den Spielraum der drei Dimensionen definiert.
Wer die Geschwindigkeit erhöht, indem Qualitätsmaßnahmen reduziert werden, ob bewusst oder unbewusst, erkauft sich kurzfristige Verbesserungen mit langfristig steigenden Kosten. Weniger Code-Reviews, weniger Tests, weniger Refactoring bedeuten zunächst schnellere Feature-Auslieferung. Doch die dadurch entstehenden Qualitätsprobleme erzeugen Bugfixes, Nacharbeiten und steigende Komplexität, die den Durchsatz mittelfristig senken und die Vorhersagbarkeit untergraben. Die Analyse der Zinseszinsen technischer Schulden zeigt, wie dieser Mechanismus funktioniert und warum die Kosten nicht linear, sondern exponentiell wachsen.
Qualität als Constraint zu verstehen bedeutet: Es gibt einen Boden, unter den man nicht fallen darf, ohne das gesamte System zu destabilisieren. Die drei Dimensionen der Lieferfähigkeit lassen sich nur innerhalb dieses Rahmens optimieren. Wer den Rahmen verletzt, gewinnt kurzfristig auf einer Dimension und verliert mittelfristig auf allen dreien. Das ist kein theoretisches Risiko, sondern ein Muster, das in der Praxis mit bemerkenswerter Regelmäßigkeit auftritt.
Ein hilfreiches Denkmodell ist die Unterscheidung zwischen schnell sein und sich beeilen. Schnell sein bedeutet, dass ein System effizient arbeitet und Ergebnisse zügig durchlaufen. Sich beeilen bedeutet, dass Abkürzungen genommen werden, die kurzfristig Zeit sparen und langfristig Kosten verursachen. Das erste ist nachhaltig. Das zweite ist ein Kredit auf die Zukunft, mit Zinsen. Organisationen, die diese Unterscheidung nicht treffen, interpretieren sinkende Geschwindigkeit oft als Grund, noch mehr Abkürzungen zu nehmen, und beschleunigen damit die Abwärtsspirale. Die Erkenntnis, dass Qualität kein Luxus ist, den man sich leistet, wenn Zeit übrig ist, sondern die Voraussetzung für nachhaltige Lieferfähigkeit, ist für viele Führungskräfte eine unbequeme Wahrheit. Sie bedeutet nämlich, dass Investitionen in Codequalität, Testabdeckung und Refactoring keine Verlangsamung darstellen, sondern eine Investition in zukünftige Geschwindigkeit, Durchsatz und Vorhersagbarkeit.
„Wie schnell können wir auf Marktveränderungen reagieren?“ Diese Frage kommt in strategischen Diskussionen regelmäßig auf den Tisch. Sie klingt nach einer eigenständigen Anforderung an ein Entwicklungssystem, und genau darin liegt ein verbreiteter Denkfehler. Reaktionsfähigkeit ist kein separater Hebel, an dem man drehen kann. Sie ist ein Resultat, das aus dem Zusammenspiel der drei Dimensionen entsteht.
Ein System, das schnell arbeitet, also geringe Durchlaufzeiten hat, kann auf neue Anforderungen zeitnah reagieren, weil die Vorlaufzeit gering ist. Ein System mit hohem Durchsatz kann neue Prioritäten aufnehmen, ohne den bestehenden Lieferstrom vollständig zu unterbrechen. Ein System mit hoher Vorhersagbarkeit kann verlässlich zusagen, wann eine Reaktion auf eine Marktveränderung wirksam wird, und damit strategische Entscheidungen ermöglichen.
Fehlt eine der drei Dimensionen, leidet die Reaktionsfähigkeit, auch wenn die anderen zwei gut funktionieren. Schnelle Durchlaufzeiten bei niedriger Vorhersagbarkeit bedeuten: Die Organisation reagiert manchmal schnell und manchmal gar nicht, ohne vorher sagen zu können, welcher Fall eintreten wird. Hoher Durchsatz bei langen Durchlaufzeiten bedeutet: Es wird viel produziert, aber auf neue Anforderungen kann erst mit großer Verzögerung reagiert werden.
Reaktionsfähigkeit lässt sich also nicht direkt messen oder gezielt optimieren. Sie verbessert sich als Konsequenz, wenn an den drei Stellschrauben Geschwindigkeit, Durchsatz und Vorhersagbarkeit systematisch gearbeitet wird, ohne den Qualitäts-Constraint zu verletzen. Das macht sie zu einem nützlichen Prüfstein: Wer die Reaktionsfähigkeit seiner Organisation verbessern will, muss sich fragen, welche der drei Dimensionen aktuell der begrenzende Faktor ist. Die Antwort darauf ist selten offensichtlich, lässt sich aber mit den richtigen Daten ermitteln. Ein System, das unter hoher Last steht und viel parallel abarbeitet, wird vermutlich an der Geschwindigkeitsdimension scheitern, weil Wartezeiten und Kontextwechsel dominieren. Ein System, das sauber fokussiert arbeitet, aber an komplexen Abhängigkeiten leidet, wird eher an der Vorhersagbarkeitsdimension scheitern, weil die Variabilität durch externe Faktoren hoch ist.
Die drei Dimensionen sind nicht unabhängig voneinander, und genau das macht die Steuerung anspruchsvoll. Geschwindigkeit und Durchsatz hängen über die Menge gleichzeitig laufender Arbeit zusammen. Dieser Zusammenhang, den Little’s Law mathematisch beschreibt, ist in der Softwareentwicklung empirisch gut belegt: Weniger parallele Arbeit führt in der Regel sowohl zu schnelleren Durchlaufzeiten als auch zu höherem Durchsatz. Vorhersagbarkeit wiederum verbessert sich häufig als Nebeneffekt, wenn die Variabilität im System sinkt, und die Begrenzung gleichzeitiger Arbeit reduziert Variabilität.
Das klingt zunächst nach einer guten Nachricht: Ein Hebel, der alle drei Dimensionen verbessert, scheint ein offensichtlicher Startpunkt zu sein. In der Praxis scheitert die Umsetzung jedoch häufig an kulturellen und organisatorischen Widerständen. Weniger parallele Arbeit bedeutet, dass manche Aufgaben bewusst nicht sofort begonnen werden. In Organisationen, die Auslastung mit Produktivität gleichsetzen, ist das ein schwer verdauliches Konzept. Der Mythos der 100%-Auslastung beschreibt die Mechanik hinter dieser Denkfalle.
Neben dem Zusammenspiel der Dimensionen gibt es eine Reihe typischer Fehlschlüsse, die in der Praxis immer wieder auftreten.
Der erste und verbreitetste Fehlschluss lautet: „Wir müssen bei allem besser werden.“ Das klingt ambitioniert, ist aber in der Realität unrealistisch und kontraproduktiv. In einem System mit begrenzten Ressourcen und konkurrierenden Zielen braucht es eine bewusste Priorisierung. Die Frage ist nicht „Wie verbessern wir alles gleichzeitig?“, sondern „Welche Dimension limitiert uns aktuell am stärksten?“ In der Regel ist die Antwort überraschend klar, wenn man die richtigen Daten betrachtet.
Der zweite Fehlschluss ist die Annahme, dass Geschwindigkeit die wichtigste Dimension sei. Für operative Teams mag das zutreffen. Für die meisten Stakeholder ist Vorhersagbarkeit oft wertvoller. Ein CTO, der verlässlich kommunizieren kann, dass ein Feature in vier Wochen ausgeliefert wird, hat mehr Handlungsspielraum als einer, der „vielleicht in zwei, vielleicht in acht Wochen“ sagen muss. Verlässlichkeit schafft Vertrauen, und Vertrauen ist die Währung, mit der Entwicklungsabteilungen Handlungsspielraum kaufen.
Der dritte Fehlschluss betrifft den Zusammenhang von Kapazität und Durchsatz: „Mehr Leute bedeuten mehr Durchsatz.“ Bis zu einem gewissen Punkt stimmt das. Darüber hinaus steigen die Koordinationskosten schneller als die zusätzliche Kapazität, und der Nettoeffekt wird negativ. Frederick Brooks hat dieses Phänomen bereits 1975 in „The Mythical Man-Month“ beschrieben, und fünfzig Jahre später begehen Organisationen denselben Fehler mit unveränderter Regelmäßigkeit. Durchsatz lässt sich nachhaltiger steigern, indem Hindernisse im bestehenden System beseitigt werden, als indem neue Kapazität hinzugefügt wird.
Abschließend lohnt der Blick zurück auf die Stakeholder-Analyse. Welche Dimension für welche Zielgruppe primär relevant ist, variiert systematisch: Die Geschäftsführung interessiert sich in erster Linie für Vorhersagbarkeit, weil sie Roadmap-Commitments gegenüber Kunden und Investoren absichern muss. Der CTO oder VP Engineering blickt auf alle drei Dimensionen, mit besonderer Fokussierung auf systemische Engpässe, die den Durchsatz begrenzen. Product Owner priorisieren häufig Geschwindigkeit, weil sie den Druck spüren, Features schnell an den Markt zu bringen. Und das Entwicklungsteam selbst profitiert vor allem davon, wenn die Menge gleichzeitig laufender Arbeit kontrolliert wird, was alle drei Dimensionen verbessert und nebenbei den Arbeitsalltag erträglicher macht.
Lieferfähigkeit ist kein eindimensionaler Begriff, auch wenn er in der täglichen Kommunikation oft so behandelt wird. „Schneller liefern“ greift zu kurz, weil es verdeckt, dass Geschwindigkeit nur eine von drei Dimensionen ist, neben Durchsatz und Vorhersagbarkeit. Qualität bildet den Rahmen, innerhalb dessen alle drei Dimensionen optimiert werden können, und Reaktionsfähigkeit entsteht als Resultat, wenn die drei Dimensionen im Zusammenspiel funktionieren.
Dieses Modell ist keine akademische Übung. Es hat direkte praktische Konsequenzen für die Frage, welche Metriken eine Organisation einführen sollte. Denn Metriken machen nur Sinn, wenn klar ist, welche Dimension sie abbilden und welche Frage sie beantworten. Cycle Time adressiert eine andere Dimension als Throughput, und beide zusammen erzählen eine andere Geschichte als isoliert betrachtet. Wie sich diese Zusammenhänge konkret messen lassen und welche Rolle Work-in-Progress als zentraler Steuerungshebel dabei spielt, würde den Rahmen dieses Artikels sprengen, ist aber ein eigenständiges und lohnendes Thema.
Das Fundament steht jetzt auf zwei Ebenen: Wir wissen, für wen und warum gemessen wird. Und wir wissen, was Lieferfähigkeit umfasst. Damit ist die Voraussetzung geschaffen, über konkrete Kennzahlen zu sprechen, ohne in die Falle eindimensionaler Optimierung zu tappen.
Buchen Sie jetzt Ihre kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.