Zum Hauptinhalt springen
EngpassAudit engpassaudit.de

Wissensbeitrag & Audio-Episode

Warum Teams trotz Vollbeschäftigung nichts fertigstellen

Volle Kalender, volle Sprint-Boards und trotzdem wenig Fertigstellung: Warum hohe Auslastung in variablen Arbeitssystemen zu längeren Warteschlangen, schlechterer Planbarkeit und immer mehr paralleler Arbeit führen kann.

Veröffentlicht am

Audiofolge anhören

Hinweis zur Erstellung: Diese dialogische Audiofolge wurde mithilfe generativer KI erstellt und von Tobias Deichmann fachlich geprüft und redaktionell freigegeben. Der Text auf dieser Seite ordnet die Kernaussagen eigenständig ein und ist kein wortgetreues Transkript.

In dieser Folge:

  • Unterschied zwischen Auslastung, Durchsatz und Fertigstellung
  • Warum es keine universelle optimale Auslastungsquote gibt
  • Was Kingmans Näherung tatsächlich aussagt
  • Warum mehr Personal einen Engpass nicht automatisch löst
  • Wie Engpasskarten Beobachtungen, Hypothesen und Evidenz trennen

01 · Grundlagen

Unterschied zwischen Auslastung, Durchsatz und Fertigstellung

In vielen Produktentwicklungs- und Engineering-Organisationen gilt die Annahme: Wenn alle Entwickler, Tester und Produktexperten vollständig beschäftigt sind, wird maximal viel geleistet. In der Praxis der Software-Delivery ist hohe Beschäftigung jedoch nicht automatisch mit hohem Ende-zu-Ende-Durchsatz verbunden.

Um zu verstehen, warum volle Sprint-Boards nicht automatisch zu ausgeliefertem Kundennutzen führen, müssen drei zentrale Größen sauber unterschieden werden:

Kapazitätsnutzung

Auslastung (Utilization)

Anteil der wirksamen Kapazität einer definierten Ressource, der in einem festgelegten Zeitraum gebunden ist. Ohne klare Ressourcengrenze und Messlogik ist eine Prozentangabe nicht belastbar.

Systemfluss

Durchsatz (Throughput)

Anzahl klar definierter Arbeitseinheiten, die das betrachtete System pro Zeiteinheit vollständig durchlaufen.

Wirksamer Output

Fertigstellung (Completion)

Arbeit, die nicht nur begonnen oder lokal abgeschlossen wurde, sondern innerhalb der gewählten Systemgrenze tatsächlich nutzbar oder lieferbar ist.

Hohe Auslastung beschreibt zunächst die Beanspruchung einer Ressource. Durchsatz und Fertigstellung beschreiben dagegen Ergebnisse des betrachteten Gesamtsystems. Wenn zusätzliche Arbeit begonnen wird, ohne dass der begrenzende Teil des Flusses mehr fertigstellen kann, steigen WIP und Wartezeiten, während der Ende-zu-Ende-Durchsatz stagnieren oder sinken kann.

02 · Systemdynamik

Warum es keine universelle optimale Auslastungsquote gibt

Manager fragen häufig: „Was ist die optimale Auslastungsquote für mein Engineering-Team?“ Darauf gibt es keinen allgemeingültigen Prozentwert. Welche Reserve ein System benötigt, hängt unter anderem von Variabilität, Aufgabenstruktur, Abhängigkeiten, Risiken und der gewünschten Reaktionsfähigkeit ab.

Geringe Variabilität

Wenn Ankünfte, Bearbeitungszeiten und Abhängigkeiten sehr gleichförmig sind, kann ein System eine vergleichsweise hohe Auslastung verkraften. Auch dann muss die Aussage auf eine klar definierte Ressource und Systemgrenze bezogen bleiben.

Softwareentwicklung & Engineering

Produktentwicklung ist wissensintensive Arbeit mit schwankenden Aufwänden, Rückfragen, unbekannten Fehlern und komplexen Abhängigkeiten. Je näher ein solches System seiner wirksamen Kapazitätsgrenze kommt, desto stärker können bereits kleine Schwankungen Warteschlangen und Durchlaufzeiten erhöhen.

Eine feste Grenze wie 80 oder 85 Prozent lässt sich daraus nicht ableiten. Entscheidend ist, ob das konkrete System genug Reserve besitzt, um Störungen, dringende Entscheidungen und schwankende Bearbeitungszeiten aufzufangen.

03 · Warteschlangentheorie

Was Kingmans Näherung tatsächlich aussagt

Kingmans Näherung beschreibt unter Modellannahmen die mittlere Wartezeit in einer einzelnen Warteschlange. Sie ist eine hilfreiche Illustration dafür, wie Variabilität und hohe Auslastung zusammenwirken. Sie ist jedoch kein direkter Beweis für die Ursache eines konkreten Delivery-Problems und keine universelle Teamformel.

Wq ≈ ((ca2 + cs2) / 2) · (u / (1 − u)) · ts

  • Variabilitätsfaktor ((ca2 + cs2) / 2): Modelliert die Streuung der Ankunfts- und Bearbeitungszeiten.
  • Auslastungsfaktor (u / (1 − u)): Steigt stark nichtlinear, wenn die modellierte Auslastung u gegen 1 geht.
  • Bearbeitungszeit (ts): Mittlere Bedien- beziehungsweise Netto-Bearbeitungszeit im Modell.

Die Kernerkenntnisse für Führungskräfte:

  1. Stark nichtlinearer Auslastungsterm: Im Modell steigt u / (1 − u) von rund 2,33 bei 70 Prozent auf 9 bei 90 Prozent und auf 19 bei 95 Prozent. Das ist ein hyperbolischer, streng nichtlinearer Verlauf. Die Werte illustrieren die Empfindlichkeit nahe der Kapazitätsgrenze; sie prognostizieren nicht unmittelbar die reale Wartezeit eines Teams.
  2. Variabilität verstärkt Wartezeiten: Schwankende Ankünfte und Bearbeitungszeiten erhöhen im Modell die mittlere Wartezeit. Welche Faktoren in einer realen Organisation dominieren, muss anhand ihrer Daten, Falltraces und Abläufe untersucht werden.
  3. Wartezeit muss gemessen werden: Features können auf Reviews, Testumgebungen, Freigaben oder Entscheidungen warten. Wie groß dieser Anteil an der Durchlaufzeit tatsächlich ist, lässt sich aber nur für eine definierte Systemgrenze und Itemklasse ermitteln.

04 · Management-Symptome

Warum mehr Personal einen Engpass nicht automatisch löst

Wenn Termine rutschen und die Liste offener Wünsche wächst, liegt der Gedanke an zusätzliche Entwicklungskapazität nahe. Das kann helfen, wenn diese Kapazität den tatsächlichen Engpass entlastet. In einem bereits verspäteten Softwareprojekt oder bei einem Engpass an anderer Stelle können Einarbeitung, zusätzliche Koordination und mehr parallele Arbeit die Situation jedoch zunächst verschärfen.

1. Einarbeitungs- und Kommunikationslast

Neue Teammitglieder benötigen Unterstützung durch erfahrene Personen. Die Formel n(n − 1) / 2 beschreibt nur die Zahl möglicher paarweiser Kommunikationsbeziehungen – nicht den tatsächlich entstehenden Aufwand, macht aber die wachsende Koordinationskomplexität sichtbar.

2. Mehr parallele Arbeit

Wenn zusätzliche Kapazität vor allem dazu führt, weitere Themen zu beginnen, wächst der Bestand offener Arbeit. Das kann nachgelagerte Entscheidungen, Integrationsschritte oder Prüfungen zusätzlich belasten.

3. Kapazität außerhalb des Engpasses

Liegt die Begrenzung bei Anforderungen, Integration, Testumgebungen, Freigaben oder einer seltenen Spezialkompetenz, erhöht zusätzliche Code-Erstellung nicht automatisch den Ende-zu-Ende-Durchsatz.

05 · Systemische Diagnose

Wie Engpasskarten Beobachtungen, Hypothesen und Evidenz trennen

Eine Engpasskarte hilft, wahrgenommene Symptome, messbare Signale, Ursachenhypothesen und überprüfbare Führungsentscheidungen auseinanderzuhalten. Sie ersetzt keine Ursachenprüfung und behauptet nicht, dass ein einzelner Messwert den Engpass beweist.

Ebene Fiktives Beispiel im Auslastungskontext Diagnostischer Nutzen
Wahrgenommenes Symptom „Das Team liefert zugesagte Vorhaben wiederholt nicht im erwarteten Zeitraum ab.“ Beschreibt die beobachtete Wirkung, aber noch keine Ursache.
Messbares Signal Der WIP steigt; ausgewählte Vorhaben altern vor Abnahme und Freigabe deutlich länger als in der aktiven Bearbeitung. Markiert einen Bereich für die weitere Untersuchung. Tooldaten bleiben abhängig von Statusdefinitionen und Datenpflege.
Ursachenhypothese Häufige Prioritätswechsel und gebündelte Abnahmen könnten mehr parallele Arbeit und Entscheidungswartezeit erzeugen. Formuliert eine prüfbare Erklärung, nicht bereits den bewiesenen Engpass.
Gegenhypothese und Evidenzprüfung Alternativ könnten fehlende Testumgebungen oder externe Freigaben dominieren. Falltraces und Interviews prüfen beide Erklärungen. Reduziert vorschnelle Kausalbehauptungen und macht widersprechende Evidenz sichtbar.
Führungsentscheidung oder Experiment Für eine definierte Itemklasse WIP begrenzen und Abnahmen häufiger durchführen; Wirkung auf Alter, Wartezeit und Durchsatz beobachten. Verbindet die Hypothese mit einem überprüfbaren Eingriff und vorher festgelegten Signalen.

Eine konkrete Beispiel-Engpasskarte ansehen, wie Beobachtungen, Evidenz, Ursachenhypothesen und Maßnahmen im Audit strukturiert werden.

Quellen und theoretischer Rahmen

Verwendete Quellen

Die Modelle und Quellen beschreiben Beziehungen und mögliche Systemeffekte. Sie belegen keine konkrete Ursache in einem einzelnen Unternehmen; dafür müssen Systemgrenze, Itemklasse, Datenqualität und reale Abläufe untersucht werden.

Nächster Schritt

Sie erkennen ähnliche Muster in Ihrer Entwicklung?

In einem unverbindlichen Vorgespräch klären wir in 20 Minuten, ob ein auf zehn Arbeitstage begrenzter EngpassAudit für Ihre Situation sinnvoll ist.

Audit-Fit in 20 Minuten prüfen Beispiel-Engpasskarte ansehen

Alle Einblicke ansehenZum Technical Product & Delivery Audit