Die Bearbeitung wird schneller. Doch die Lieferzeit bleibt, wie sie war.
Dieser Befund häuft sich in Organisationen, die begonnen haben, größere Teile der Softwareentwicklung an KI-gestützte Werkzeuge zu übergeben. Die Erklärung dafür ist bekannt und in dieser Serie mehrfach berührt: Der aktive Anteil an der gesamten Lieferzeit ist klein. Und was ihn umgibt, ist Wartezeit, die von schnelleren Werkzeugen unberührt bleibt.
Weniger beachtet ist eine zweite Erklärung, die der ersten vorausgeht. Die Zahl, an der das Ausbleiben der Verbesserung festgemacht wird, hat an keinem ihrer beiden Enden eine technisch bestimmte Grenze. Wo die Messung beginnt und wo sie endet, wurde irgendwann festgelegt, meist nebenbei und meist danach, wo im Ticketsystem ein Datum zur Verfügung stand. Beide Festlegungen entscheiden darüber, wie groß der gemessene Ausschnitt ist und welcher Teil der Organisation darin überhaupt vorkommt.
Dieser Artikel behandelt diese beiden Grenzen: den Punkt, an dem die Uhr zu laufen beginnt, und den Punkt, an dem sie stehen bleibt.
Cycle Time, der Durchsatz (Throughput) und der Bestand an gleichzeitig laufender Arbeit (Work-in-Progress) haben eine Eigenschaft, die selten auffällt, weil sie so selbstverständlich ist: Ihre Grenzen sind im Ticketsystem hinterlegt. Ein Zustandswechsel auf dem Board markiert den Beginn der aktiven Arbeit, ein zweiter ihr Ende, und beide Ereignisse liegen als Zeitstempel vor. Was gemessen wird, ist damit nicht ausgehandelt, sondern konfiguriert.
Bei der Lead Time ist das anders. Sie umfasst, wie in Cycle Time, Throughput und Work-in-Progress beschrieben, die Zeitspanne aus Sicht der Anfordernden, also von der Formulierung eines Bedarfs bis zur Auslieferung. Nur ist weder das eine noch das andere ein Ereignis, das ein System protokolliert. Kein Werkzeug kennt den Moment, in dem jemand einen Bedarf hat. Und der Moment, in dem ein Ergebnis tatsächlich beim Adressaten ankommt, liegt in den meisten Organisationen hinter mehreren Schritten, die kein gemeinsames Protokoll führen.
Was in der Praxis geschieht, ist deshalb vorhersehbar. Die Grenzen wandern dorthin, wo ohnehin ein Datum liegt: auf das Anlagedatum eines Vorgangs und auf den Zustandswechsel nach „Done“. Das ist der Streetlight-Effekt, der im Auftakt dieser Serie für die Auswahl von Kennzahlen beschrieben wurde, angewandt auf ihre Ränder. Gemessen wird, wo es hell ist.
Wie folgenreich das ist, zeigt ein prominentes Beispiel. Die DORA-Kennzahlen führen eine Größe namens Lead Time for Changes, und diese misst vom Commit bis zum Lauf in Produktion. Für ihren Zweck ist der Schnitt sauber gewählt, denn sie soll die technische Auslieferungsfähigkeit beurteilen und nicht die Reaktionszeit einer Organisation. Nur trägt der Name einen Anspruch, den die Messung nicht einlöst. Vorne fehlt alles bis zum ersten Commit und hinten alles nach dem Deployment.
Die beiden Grenzen haben dabei etwas gemeinsam, das sich erst zeigt, wenn man sie nebeneinanderlegt. Sie markieren nicht den Anfang und das Ende der Wartezeit, sondern den Anfang und das Ende der Zuständigkeit.
Für den Startpunkt sind vier Festlegungen gebräuchlich, und jede misst etwas anderes.
Die Anlage des Vorgangs ist die häufigste, weil sie die einzige ist, die keine Arbeit macht. Das Feld existiert, es wird automatisch gefüllt, und niemand muss eine Entscheidung treffen. Gemessen wird damit ab dem Moment der Formalisierung. Alles, was davor geschah, also die Klärung, ob der Bedarf überhaupt aufgenommen wird, die Rückfragen oder die Weiterleitung zwischen Zuständigkeiten, liegt außerhalb.
Die Aufnahme in ein priorisiertes Backlog verschiebt die Grenze nach hinten und misst damit im Wesentlichen den Durchsatz der Priorisierung. Vorgänge, die angelegt wurden und nie priorisiert werden, tauchen in der Statistik nie auf.
Das Commitment oder die Einplanung ist eine beliebte Wahl in Organisationen, die ihre Zahlen für die Steuerung von Teams verwenden. Sie ist zugleich die uninformativste, denn sie schneidet die Lead Time auf einen Bereich zurecht, der sich von der Cycle Time kaum noch unterscheidet. Was übrig bleibt, ist eine zweite Messung derselben Sache unter einem anderen Namen.
Die Entstehung des Bedarfs ist die einzige Festlegung, die der Definition tatsächlich entspricht, und die einzige, die sich nicht flächendeckend erheben lässt. Es gibt kein Feld dafür und es wird auch keines geben.
Der Mechanismus, der in diesem Abschnitt Zeit erzeugt, ist eine Warteschlange. Arbeit staut sich, weil mehr hereinkommt, als entschieden oder begonnen wird, und die Wartezeit wächst mit dem Bestand vor dem System überproportional, wie im Artikel zu den Kosten hoher Auslastung beschrieben. Wer die Messgrenze hinter diese Warteschlange legt, misst ein System, dessen größte Zeitsenke außerhalb des Messbereichs liegt.
Damit entsteht eine leise Variante eines bekannten Problems. Der Auftakt dieser Artikelserie beschreibt, wie eine zum Ziel erklärte Lead Time dazu führt, dass Vorgänge künstlich klein geschnitten werden. Die Verschiebung der Messgrenze erreicht dasselbe Ergebnis, ohne dass irgendjemand seine Arbeitsweise ändern müsste. Sie sieht nach Konfiguration aus, nicht nach Beeinflussung, und sie hinterlässt keine Spur in den Daten. Eine Zahl, die nach der Anpassung der Systemgrenze besser aussieht, hat sich nicht verbessert.
Praktisch lässt sich der unsichtbare Teil nicht messen, aber schätzen. Zehn abgeschlossene Vorhaben zurückverfolgen und für jedes das Anlagedatum gegen die früheste auffindbare Erwähnung stellen, sei es in einer Mail, einem Protokoll oder einem Kommentar, liefert eine Größenordnung. Eine Größenordnung reicht für die Frage, um die es hier geht, nämlich ob der nicht gemessene Teil klein oder beherrschend ist.
Am anderen Ende steht ein Zustand, dessen Bedeutung noch weniger festgelegt ist. „Done“ ist keine technische Angabe, sondern eine Vereinbarung. Was sie umfasst, unterscheidet sich zwischen Organisationen erheblich. In der einen bedeutet der Zustand, dass Code zusammengeführt und geprüft wurde. In der nächsten, dass die Änderung in Produktion läuft. In einer dritten, dass eine fachliche Abnahme erfolgt ist.
Über alle Varianten hinweg bleibt eine Gemeinsamkeit. Der Zustand markiert den Punkt, an dem das Team nichts mehr zu tun hat, nicht den Punkt, an dem jemand das Ergebnis nutzen kann. Was dazwischen liegt, hat je nach Organisation verschiedene Formen, und jede erzeugt Wartezeit auf ihre eigene Weise:
Der Mechanismus dahinter ist ein anderer als am vorderen Rand und das ist die praktisch wichtigste Beobachtung dieses Artikels. Hier staut sich nichts wegen Überlast. Die Arbeit ist fertig, die Kapazität ist frei und trotzdem vergeht Zeit, weil ausgeliefert wird, wenn der Takt es vorsieht und nicht, wenn etwas fertig ist. Die Wartezeit hängt hier an der Frequenz, nicht am Bestand. Wie lange ein einzelnes Ergebnis liegen bleibt, entscheidet sich hauptsächlich danach, wie kurz vor dem nächsten Termin es fertig wurde. Über viele Vorgänge hinweg bewegt sich dieser Anteil in der Größenordnung eines halben Auslieferungsintervalls. Und der wird nicht dadurch kleiner, dass davor schneller gearbeitet wurde.
Daraus folgt zweierlei. Erstens greifen die Hebel aus dem vorderen Teil hier nicht. Eine Begrenzung des Bestands verkürzt Warteschlangen, aber sie verändert keinen Freigabetermin. Wer diesen Abschnitt verkürzen will, muss an der Frequenz und an der Größe der ausgelieferten Pakete arbeiten. Beides sind Entscheidungen, die selten beim Team liegen.
Zweitens ist dieser Abschnitt der einzige, in dem eine Beschleunigung davor vollständig verpufft. Ein Ergebnis, das in drei statt in zehn Tagen fertig wird, wartet danach genauso lange auf den nächsten Termin wie zuvor. Für die Adressaten ändert sich in diesem Fall nichts, während sämtliche Kennzahlen des Teams eine Verbesserung anzeigen. Das ist die Konstellation, an der in Wie aus Kennzahlen Entscheidungen werden die Grenze der Steuerung auf Teamebene sichtbar wird, hier allerdings nach der Fertigstellung statt davor.
Soweit KI-gestützte Werkzeuge heute Wirkung entfalten, liegt diese Wirkung überwiegend in der Mitte, also beim Entwurf, bei der Implementierung und beim Testen. Das gilt nicht überall gleich. Wo solche Werkzeuge auch in der Klärung und in der Spezifikation eingesetzt werden, verkürzt sich ein Teil des vorderen Abschnitts mit. Das verschiebt die Anteile, ändert aber nichts am Muster, denn beide Ränder bestehen überwiegend aus Wartezeit und nicht aus Arbeit, und Wartezeit lässt sich nicht schneller ausführen.
Zwei Effekte kommen hinzu, die in die Gegenrichtung wirken.
Vorne wächst der Zufluss. Wenn Entwürfe, Analysen und Prototypen billiger werden, sinkt die Hürde, etwas anzufangen. Es entstehen mehr Vorhaben, und mehr Vorhaben bedeuten eine längere Warteschlange vor dem System. Genau diese Warteschlange liegt bei den gebräuchlichen Festlegungen außerhalb der Messung.
Hinten wachsen die Pakete. Steigt der Durchsatz, während die Auslieferungsfrequenz unverändert bleibt, sammelt sich pro Release-Termin mehr an. Größere Pakete enthalten mehr voneinander abhängige Änderungen, sind aufwendiger zu prüfen und schwerer zurückzunehmen. Freigabe und Abnahme werden dadurch nicht schneller, sondern eher langsamer. Der hintere Abschnitt bleibt also nicht nur unverändert, er kann sich verlängern.
Die gemessene Zahl kann damit sinken, während die Zeit zwischen Bedarf und Nutzung gleich bleibt oder steigt. Beide Beobachtungen sind dann zutreffend und widersprechen einander nur scheinbar. Wer den gemessenen Ausschnitt für das Ganze hält, wird die falsche von beiden infrage stellen, nämlich die Rückmeldung der Adressaten.
Die naheliegende Antwort auf all das ist eine Zerlegung: die Lead Time in Bearbeitungszeit und Wartezeit aufteilen und sehen, wo die Zeit bleibt. Diese Zerlegung setzt allerdings voraus, dass Warten im Workflow als eigener Zustand existiert. Wo ein einzelner Zustand „In Arbeit“ beides umfasst, ist die Aufteilung keine Frage der Auswertung, sondern eine Änderung am Workflow, die vor der Messung stattfinden muss. Sie kostet die Beteiligten zusätzliche Pflegearbeit an jedem Vorgang, und das ist der übliche Grund, warum es sie nicht gibt.
Wo ein Wartestatus existiert und tatsächlich gesetzt wird, ist die Flow-Effizienz berechenbar, also das Verhältnis der aktiven Bearbeitungszeit zur gesamten Lead Time. Der Begriff und das Effizienzparadoxon dahinter gehen auf Niklas Modig und Pär Åhlström in „This is Lean“ zurück und sind in Was Lieferfähigkeit in der Softwareentwicklung bedeutet eingeführt.
Zwei Einschränkungen begleiten diese Rechnung.
Die erste betrifft die Diagnose. Ein einzelner Wartestatus sagt, dass gewartet wurde, nicht, worauf. Warten auf eine Prüfung, auf die Zuarbeit eines anderen Bereichs, auf eine Freigabe und auf eine Umgebung landen im selben Topf, und die Hebel dagegen sind vollkommen verschiedene. Wo der Grund im Kommentar festgehalten wird, ist er lesbar, aber nicht auswertbar. Der praktikable Weg führt dann über eine Stichprobe: fünfzig Vorgänge durchsehen und die Gründe auszählen. Das ergibt eine Verteilung, die für die Entscheidung genügt, wo anzusetzen ist. Das ist deutlich weniger Aufwand, als es klingt.
Die zweite betrifft die Reichweite. Ein Wartestatus liegt in aller Regel zwischen Beginn und Fertigstellung. Vor dem Beginn und nach der Fertigstellung wartet ein Vorgang zwar ebenfalls, aber in diesen Phasen ist niemand dafür zuständig, seinen Zustand zu pflegen. Die Instrumentierung zieht damit dieselbe Grenze wie die Kennzahl und sie zieht sie aus demselben Grund.
Für die Flow-Effizienz selbst folgt daraus, dass sie als Vergleichswert zwischen Organisationen nicht taugt. Ihr Wert hängt vollständig davon ab, wie fein die Zustände modelliert sind und wo die Systemgrenzen liegen. Beides ist zwischen zwei Organisationen nie gleich. Als eigene Zeitreihe über Monate hinweg ist sie dagegen aussagekräftig, sofern die Modellierung unverändert bleibt.
Eine Besonderheit kommt in der aktuellen Lage hinzu. Schrumpft die Bearbeitungszeit bei weitgehend unveränderter Wartezeit, dann sinkt die Flow-Effizienz, denn ihr Zähler wird kleiner und ihr Nenner kaum. Eine erfolgreiche Werkzeugeinführung verschlechtert also die Kennzahl. Wer sie als Zielgröße führt und nicht als Beobachtungsgröße, bestraft damit genau das, was er erreichen wollte. Lesbar bleibt der Verlauf nur, wenn Zähler und Nenner getrennt betrachtet werden, wenn also die absolute Bearbeitungszeit neben der absoluten Wartezeit steht.
Die Lead Time ist die einzige der hier behandelten Kennzahlen, deren Grenzen nicht gemessen, sondern gesetzt werden. Beide Setzungen folgen in der Praxis nicht dem Verlauf der Wartezeit, sondern dem Verlauf der Zuständigkeit. Vorne beginnt die Messung dort, wo ein Vorgang zur Sache des Teams wird, hinten endet sie dort, wo er es nicht mehr ist. Was übrig bleibt, ist eine Zahl über den Bereich, für den ohnehin jemand geradesteht, und Schweigen über den Rest.
Beide Ränder gehorchen dabei verschiedenen Gesetzen. Vor dem Beginn wirkt eine Warteschlange, deren Länge am Bestand hängt. Nach der Fertigstellung wirkt ein Takt, dessen Wirkung an der Frequenz hängt und den keine Beschleunigung davor verkürzt. Wer beide Abschnitte mit denselben Hebeln bearbeitet, wird an einem von ihnen scheitern.
Die Frage, ab wann gezählt wird und bis wann, sieht nach einer Konfigurationsentscheidung aus. Sie ist eine Entscheidung darüber, welcher Teil der Organisation in der Zahl vorkommt und welcher unsichtbar bleibt. Solange die Entwicklung den größten Teil der Zeit ausmachte, war der Unterschied verschmerzbar. Diese Zeit geht gerade zu Ende. Wenn es sie überhaupt je gab.
Buchen Sie jetzt Ihre kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.