Lead Time vs. Cycle Time - Lean Software Development

1Definitionen, die zählen

Diese Begriffe werden häufig verwechselt, sind aber entscheidend unterschiedlich:

Lead Time: Die gesamte verstrichene Zeit vom Zeitpunkt, an dem ein Kunde eine Anfrage stellt, bis er den Wert erhält. Das ist es, was der Kunde erlebt. Es umfasst alle Wartezeiten, alle Bearbeitungen, einfach alles.

Cycle Time: Die Zeit, in der an der Arbeit aktiv gearbeitet wird. Das ist es, was Mitarbeiter während ihres Teils des Streams erleben.

Beispiel: Ein Kunde fordert am Montag ein Feature an. Es wird priorisiert und am Mittwoch in die Entwicklung übernommen. Ein Entwickler arbeitet 2 Tage daran. Es liegt 3 Tage im PR-Review. Das Testen dauert 1 Tag. Es wird am Freitag der folgenden Woche deployed.

Lead Time: 12 Tage (Montag bis Freitag der Woche 2)
Cycle Time (Entwicklung): 2 Tage
Cycle Time (Review): Ein paar Stunden
Cycle Time (Testing): 1 Tag

Beachten Sie: Die aktive Arbeit betrug vielleicht insgesamt 4 Tage. Die Lead Time betrug 12 Tage. Acht Tage waren Wartezeit.

Die Metrik, die Sie wahrscheinlich tracken, ist falsch

Die meisten Teams tracken Cycle Time oder Velocity – was Mitarbeiter produzieren. Aber Kunden interessiert Ihre Velocity nicht. Sie interessiert die Lead Time – wie lange sie warten. Optimieren Sie für das, was Kunden fühlen, nicht für das, was intern gut aussieht.

2Woher die Lücke kommt

Die Lücke zwischen Lead Time und Cycle Time ist Wartezeit. Und Wartezeit dominiert typischerweise.

Queue Time: Arbeit, die in Backlogs liegt, darauf wartet, priorisiert zu werden, darauf wartet, dass jemand sie aufnimmt.

Übergabeverzögerungen: Arbeit, die in einer Phase erledigt ist, aber darauf wartet, dass die nächste Phase Kapazität hat.

Batching-Verzögerungen: Arbeit, die fertig ist, aber darauf wartet, mit anderer Arbeit zusammen deployed zu werden.

Externe Abhängigkeiten: Warten auf andere Teams, Anbieter oder Genehmigungen.

Kalenderverzögerungen: Arbeit, die bereit ist, aber „wir deployen nur dienstags".

In den meisten Softwareorganisationen macht Wartezeit 80-95% der Lead Time aus. Das bedeutet, dass nur 5-20% der Zeit tatsächlich an der Arbeit gearbeitet wird.

Die Implikation: Die Verbesserung der Arbeitsgeschwindigkeit hat minimale Auswirkungen. Wenn Sie doppelt so schnell arbeiten, aber die Wartezeiten gleich bleiben, ändert sich die Lead Time kaum. Der Hebel liegt in den Wartezeiten.

2 Stunden Arbeit, 2 Wochen Lead Time

Ein einfacher Bugfix: 2 Stunden Entwicklerzeit. Aber: 3 Tage Warten auf Zuweisung, 2 Tage Warten auf PR-Review, 1 Tag Warten auf QA, 3 Tage Warten auf das wöchentliche Deployment, 2 Tage Monitoring in Produktion. Lead Time: 11 Tage.

Gleiche Arbeit, anderes System

Gleicher Bugfix, anderes Team: PR innerhalb von Stunden reviewt (kleine PRs, Team-Priorität auf Review). Keine QA-Warteschlange (Entwickler testen ihren eigenen Code). Continuous Deployment (keine Deploy-Fenster). Lead Time: 3 Stunden.

3Touch Time und Wait Time

Eine weitere nützliche Aufschlüsselung:

Touch Time: Zeit, in der Arbeit aktiv von einem Menschen vorangebracht wird. Hände auf der Tastatur. Gehirn mit diesem Problem beschäftigt.

Wait Time: Die ganze Zeit dazwischen. In Warteschlangen. Warten auf Review. Warten auf Deployment. Warten auf Informationen.

Processing Time: Touch Time plus Maschinenzeit (Builds, Tests, Deploys). Das ist Cycle Time.

Wenn Sie diese Aufschlüsselung verstehen, können Sie Verbesserungen richtig ansetzen:

Lange Touch Time, aber hoher Mehrwert? Wahrscheinlich keine Verschwendung – das ist qualifizierte Arbeit.
Lange Touch Time, aber geringer Mehrwert? Potenzielle Verschwendung – automatisieren oder eliminieren.
Lange Wait Time? Fast sicher Verschwendung – Batches reduzieren, WIP begrenzen, Warteschlangen eliminieren.

Die meisten Teams versuchen, die Touch Time schneller zu machen (bessere Tools, mehr Entwickler), wenn das Problem die Wait Time ist (zu viel WIP, Batching, Warteschlangen). Das ist, als würde man versuchen, Autos schneller zu machen, wenn sie im Stau stehen.

Wenn Sie ein Lead-Time-Problem haben, haben Sie wahrscheinlich ein Wait-Time-Problem. Wenn Sie ein Wait-Time-Problem haben, haben Sie wahrscheinlich ein WIP-Problem. WIP zu reduzieren ist normalerweise der schnellste Weg zu kürzeren Lead Times.