Samstag, 15. Dezember 2012

Ist Little’s Law keine lineare Beziehung?


Wer sich intensiver mit Kanban beschäftigt, kommt um Little’s Law nicht herum. Diese Formel sieht einfach aus, hat es aber in sich. Immer wenn ich glaube, ich hätte verstanden, woraum genau es geht und wie man Little’s Law sinnvoll einsetzt, kommen bei mir neue Fragen auf. Deshalb ist ein ein riesiger Glücksfall, dass ich dieses Jahr in Boston Frank Vega kennen gelernt habe. Frank ist nicht nur ein unglaublich netter Mensch, sondern er ist ursprünglich auch Mathematiker. Und in unserer Community ist er sicherlich einer der größten Experten zu Little’s Law und dem ganzen Bereich der Warteschlangen-Theorie. Aus einer Frage, die ich Frank per Mail gestellt hatte, ist ein Blog Post entstenden, der für mich definitiv zu den besten Post gehört, die 2012 geschrieben wurden. Deshalb habe ich Frank gefragt, ob ich seinen Post (eigentlich ist es mehr ein Fachartikel als ein Blog Post) ins Deutsche übersetzen darf. Und er hat es erlaubt :-)

Hier also der übersetzte Text von Frank:

“Unter dem Strich lässt sich festhalten: Der größte Hebel, um Produkte schneller auszuliefern, besteht darin, sich auf die wichtigen Produkte zu fokussieren und die unwichtigen aufzugeben.“
Here’s the bottom line: the number one driver for shipping products quicker is by focusing on the important ones and killing the unimportant ones.”
“Jetzt denken Sie vielleicht: ´Das mag ja alles stimmen, aber können wir nicht auch diue durchschnittliche Fertigstellungsfrequenz (completion rate) erhöhen?´  Im Prinzip haben Sie Recht, aber der Effekt davon ist viel geringer, als wenn wir den TIP (things-in-process), also die Menge an parallelen Dingen, reduzieren. Das liegt daran, dass es sehr schwieirg ist, die durchschnittliche Fertigstellungsfrequenz zu erhöhen, denn diese ist häufig eine Funktion aus verfügbaren Ressourcen, sich ständig vermehrenden Anforderungen, Anforderungen und Veränderungen des Marktes usw.“
 You might be thinking: ‘True, but couldn’t we also increase the average completion rate’? You’re right, but the impact of doing that is much lower than reducing the TIP (things-in-process) — that is, influencing the average completion rate is rather difficult and is often a function of available resources, scope creep, market demands and changes, etc.”
- Pete Abilla, Nov 2006, Little’s Law for Product Development

Vor ein paar Wochen hat Arne Roock, ein Mitstreiter im Bereich Kanban/Lean-Agile, mir diese Frage zum Zusammenhang zwischen Little’s Law und Auslastung gestellt: „Die Warteschlangentheorie sagt uns, dass die Geschwindigkeit von Netzwerken drastisch (nicht-linear) abnimmt, sobald die Auslastung über 80% ansteigt. Gleichzeitig folgt aus Little’s Law (ein stabiles System vorausgesetzt), dass sich die Durchlaufzeit linear verlängert, in dem Maße wie wir den WIP (work-in-progress) erhöhen (was eine Erhöhung der Auslastung bedeutet). Aber müsste uns Little’s Law nicht eigentlich voraussagen, dass die Durchlaufzeit ab einem bestimmten Zeitpunkt (in etwas ab 80% Auslastung) exponenziell ansteigt?“ Aus dieser Frage entwickelte sich ein E-Mail-Austausch über Little’s Law und warum in der Softwareentwicklung ein erhöhter WIP zu einem exponenziellen Wachstum der Durchlaufzeit führen kann. In diesem Artikel gebe ich einige Gedanken aus unserer E-Mail-Diskussion wieder und spinne diese weiter. Ich könnte mir vorstellen, dass auch Andere sich über diese Fragen Gedanken gemacht haben. Falls ja, wird dieser Artikel hoffentlich nützlich sein.

Little‘s Law: In aller Kürze

Zuerst sollten wir alle auf demselben Stand sein und uns die Grundlagen zu Little’s Law ansehen. 

Hinweis: Ich habe beobachtet, dass Little’s Law je nach Kontext und Szenario ganz unterschiedlich formuliert und bezeichnet wird. Die nachfolgenden Varianten beziehen sich in erster Linie auf meine eigenen Anwendungen im Bereich der Softwareentwicklung

In der Regel wird Little’s Law wie folgt dargestellt:

L = λ W

Dabei gilt:

L = die durchschnittliche Anzahl an Aufgaben in einem Warteschlangen-System (Queuing System) innerhalb eines bestimmten Zeitabschnitts

λ = die durchschnittliche Anzahl an Aufgaben, die innerhalb eines definierten Zeitintervalls neu in das System gelangen (Ankunftsrate)

W = die durchschnittliche Zeit, die eine Aufgabe insgesamt im System verbringt

Durch simple Algebra lässt sich Little’s Law umformulieren. Wenn wir die Größen dann noch umbenennen, bekommen wir die Form,  die im Kontext der Softwareentwicklung häufig verwendet wird:

LT = WIP / Durchsatz

Dabei gilt:

LT = die durchschnittliche Lead Time, also die Durchlaufzeit, die eine Aufgabe benötigt, um durch den gesamten Workflow von Beginn bis zur Auslieferung zu gelangen

WIP = die durchschnittliche Anzahl an Aufgaben (Work in Progress), die gleichzeitig begonnen wurden und sich innerhalb eines definierten Zeitraums innerhalb des Workflows befinden

Durchsatz  = die durchschnittliche Anzahl an Aufgaben, die das System innerhalb eines definierten Zeitintervalls verlassen

Beachtenswert ist dabei, dass sich bei dieser Umstellung der Formel die ursprüngliche Ankunftsrate in den Durchsatz verwandelt – also die Frequenz, in der Aufgaben das System verlassen.
In der Softwareentwicklung nehmen Aufgaben typischerweise die Form von User Storys, Change Requests, Bug Fixes usw. an

Hinweis: Hier gibt es einen älteren Blog Post von mir, in dem ich den Unterschied zwischen Lead Time und Cycle Time diskutiere und auch darauf eingehe, welche Auswirkungen sich daraus für das Tracking von Zeiten vs. Tracking von Aufwänden ergeben.

Little‘s Law: Eine kurze Probefahrt


Nun wollen wir die zweite Darstellung von Little’s Law einmal hernehmen und eine kurze Probefahrt „im Klassenzimmer“ unternehmen. Im Grunde ist es ja ein einfaches Verhältnis: Wenn wir den Durchsatz (also den Nenner) konstant lassen, dann können wir leicht sehen, dass sich die Durchlaufzeit (Quotient) proportional verlängert in dem Maße, indem wir den WIP (Zähler) erhöhen. In diesem Schul-Beispiel gibt es keine Schwieirgkeiten, oder?
Aber wie tragfähig ist die Annahme wirklich, dass wir den Durchsatz konstant halten können, wenn wir den WIP erhöhen? Wir werden in Kürze auf diese Frage zurückkommen. Aber zuerst müssen wir alle Annahmen verstehen, auf denen Little’s Law fußt.

Little‘s Law: Annahmen


Es gibt nur wenige solcher Annahmen, und hier ist meine Zusammenfassung: Alle drei Parameter in Little’s Law müssen in derselben Einheit dargestellt sein; bei jedem Parameter handelt es sich um einen langfristigen Durchschnitt; und wir haben es mit einem stabilen System zu tun. Die erste dieser Annahmen ist trivial. Wenn wir den Durchsatz als Anzahl an erledigten Aufgaben pro Tag definieren, dann muss sich der WIP auf dieselben Aufgaben beziehen. Im Kontext der Softwareentwicklung beispielsweise kann der Durchsatz sich auf fertig gestellte Tasks pro Tag beziehen. Dann darf sich der WIP aber nicht auf User Storys beziehen.
Die letzten beiden Annahmen sind hingegen etwas kniffliger, denn sie nehmen je nach Kontext und Szenario etwas andere Formen an. Es ist wichtig, sich über diese unterschiedlichen Gestalten klar zu sein und sie zu verstehen. Aber eine ausführliche Diskussion kann in diesem Artikel nicht geleistet werden. Als weiterführende Literatur verweise ich hier auf Kapitel 5 des (englischen) Aufsatzes „ Little’s Law“ von Dr. Stephen C. Graves, Professor für Mechanical Engineering and Engineering Systems am M.I.T.
An dieser Stelle werde ich nur insoweit auf Details eingehen, wie sie in unserem Zusammenhang wichtig sind.

Little’s Law: Langfristige Durchschnitttswerte und ein stabiles System

Jetzt wird es Zeit, dass wir uns die Hände schmutzig machen und Little’s Law mitsamt seinen Annahmen einmal an einem einfachen Praxisbeispiel ausprobieren. Mein Beispiel mit den zwei Wassertanks wurde wiederum von einem anderen Beispiel inspiriert, das ich hier gefunden habe.
In den linken Tank fließt Wasser in der Menge von 8 Liter pro Stunde herein und heraus. Der Durchsatz, also die Menge an Wasser, die den Tank verlässt, bleibt konstant. Ebenso bleibt der WIP, also der Wasserstand im Tank, bleibt konstant bei 20 Litern. Weil kein Wasser am Rand des Tanks hängenbleibt, bleibt die Lead Time, die ein Wassermolekül (oder ein Liter Wasser) benötigt, um einmal durch den Tank zu fließen, ebenfalls konstant. Noch einmal zur Wiederholung: So lange wir konsistent beim Durchsatz und beim WIP  bleiben, spielt es keine Rolle, ob wir Moleküle oder Liter als Einheit nehmen – oder irgendetwas ganz Anderes, was uns gerade besser passt.


Wenn wir nun Litle’s Law anwenden, erhalten wir eine Lead Time von 2,5 Stunden (20 / 8). Wir gehen das einmal kurz durch: Wenn kein weiteres Wasser in den Tank fließen würde, dann wäre der Tank (bei gegebenem Durchsatz von 8 Litern pro Stunde) in genau 2,5 Stunden leer. Wenn wir nun genau so viel Wasser neu in den Tank füllen, wie hinausfließt, bleibt der Wasserstand konstant und es ergibt sich eine durchschnittliche Durchlaufzeit von 2,5 Stunden.
Nun erhöhen wir die Auslastung des Wassertanks. Wir lassen also so lange mehr Wasser hinein- als herausfließen, bis der neue  Wasserstand von 80 Litern erreicht ist. Danach gehen wir wieder zurück auf den vorherigen Zustand und lassen genau so viel in den Tank, wie auch hinausströmt (8 Liter / Stunde). Dabei halten wir die ganze Zeit über den Durchsatz, also die Menge an Wasser, das den Tank verlässt, konstant. Egal wie viel Wasser in den Tank fleißt, es fließt immer genau gleich viel heraus.

Hinweis: Ich konzentriere mich auf die Frage, was geschieht, wenn wir den Wip erhöhen, weil dies der Kern der Ausgangsfrage nach Little’s Law und der Auslastung eines Systems ist. Mir ist bewusst, dass es noch die verwandte Frage gibt, was geschieht, wenn wir den WIP unter eine bestimmte Menge reduzieren. Dieser Frage gehe ich jedoch in diesem Post nicht weiter nach.

In der Phase, in der mehr Wasser in den Tank gelangt als herausläuft, ist der WIP kein langfristiger Durchschnitt mehr, sondern er erhöht sich mit der Zeit. Wenn wir den WIP (=Wasserstand im Tank) erhöhen, so sagt uns Little’s Law eigentlich, dass die durchschnittliche Lead Time für die einzelnen Wassermoleküle sich verlängert. Aber ist es überhaupt zulässig, Little’s Law in der Phase anzuwenden, in der mehr Wasser in den Tank hinein- als herausfließt?
Der Durchsatz bleib zwar die ganze Zeit über konstant, in der sich der WIP erhöhte. Aber in unserem einfachen Wassertank-Beispiel haben wir erst dann wieder ein stabiles System, wenn wieder so viel Wasser in den Tank gelangt wie ihn auch wieder verlässt. Sobald das System dann wieder stabil ist, berechnet uns Little’s Law eine neue langfristige durchschnittliche Lead Time. Der neue WIP beträgt 80 Liter, der Durchsatz bleibt bei 8 Litern, also ergibt sich eine neue Lead Time von 10 Stunden. Und dieser Anstieg der Lead Time ist wiederum proportional zum Anstieg des WIP, der jetzt ja 4 mal zu groß ist wie zuvor. Man beachte, dass in den Annahmen, auf denen Little’s Law gründet, nichts über die Auslastung des Systems ausgesagt ist.

Little’s Law: Der Effekt von Auslastung

Stellt nun also Lillte’s Law eine „lineare“ Beziehung dar in dem Sinne, dass ein Anstieg im WIP immer zu einem proportionalen Anstieg der Lead Time führt? Um diese Anfangsfrage zu beantworten, müssen wir überlegen, inwieweit die Annahme zutrifft, dass wir den Durchsatz wirklich konstant halten können, wenn wir den WIP erhöhen.
Das Beispiel des Wassertanks ist ein sehr einfaches Szenario für den Einsatz von Little’s Law, weil darin ein schön gleichmäßiger und kontinuierlicher Workflow modelliert wird. Der Wert dieses Beispiels besteht für mich darin, sich klar zu machen, wie wichtig diese Annahme ist. Zu verstehen, warum wir in allen drei Parametern dieselben Einheiten brauchen, ist einfach. Jetzt ist hoffentlich auch klar geworden, warum wir langfristige Durchschnittswerte und ein stabiles System benötigen, wenn wir Little’s Law anwenden möchten.

Hinweis: Für mich ergibt sich aus dem bisher Gesagten, wie wichtig WIP-Limits sind. Selbst wenn wir zu Beginn nur ein einziges Limit für das gesamte System etablieren und dieses Limit zuerst absurd hoch zu sein scheint, so trägt dieses Limit dazu bei, ein System stabil zu machen und zu erhalten. Dadurch wird es möglich, dieses hilfreiche Werkzeug (Little’s Law) effektiv einzusetzen, um besser zu verstehen und zu lernen, wie wir unseren Workflow verbessern können. Und hierdurch können wir auch besser beurteilen, welche Maßnahmen wirklich zu Verbesserungen führen.
Ich bekomme häufiger gesagt, dass Leute keine „expliziten“ WIP-Limits haben, sie aber trotzdem in den meisten Fällen „erfolgreich“ ausliefern. Gleichzeitig haben sie eine beträchtliche Mange an Aufgaben gleichzeitig in Arbeit. Wenn ich dann ein bisschen tiefer grabe, stoße ich meistens auf einen (oder beide) der folgenden  Punkte.
Der erste Fall besteht darin, dass es eine Person gibt (meistens ein erfahrener und begabter Projektmanager), der mit „impliziten“ WIP-Limits arbeitet. Das bedeutet, er sorgt dafür, dass einige Aufgaben zurückgehalten werden, indem er den Umfang oder den Komfort von Features reduziert und sich darum kümmert, Erwartungen und sichtbare Risiken zu managen. Dies würde ich als „gutes“ Projektmanagement ansehen, aber ich stoße nicht häufig darauf. Im zweiten Fall von „impliziten“ Limits ist die Qualität verbesserungswürdig und das System erfordert erhebliches „Heldentum“ bei den Beteiligten, um zu funktionieren.
Ich beobachte eine ganze Reihe von Nachteilen, die sich aus dieser impliziten Art der Limitierung ergeben: Durch die schlechte (oder gar nicht vorhandene) Sichtbarkeit wird der Prozess noch subjektiver, häufig auch „politischer“; Umwege werden wahrscheinlicher; es gibt mehr Kontextwechsel; häufig werden mehr „ungeplante“ Überstunden fällig; es entstehen mehr Bugs und Hacks usw. Und ja: Auch explizite WIP-Limits werden manchmal ignoriert – mit ähnlichen Ergebnissen. Aber nachdem ich mit beiden Arten (explizite und implizite Limits) gearbeitet habe, lehrt mich meine Erfahrung, dass es besser ist, WIP-Limits (passend zur Leistungsfähigkeit des Systems) explizit festzulegen und zu visualisieren und dann durch Policies zu Verhaltensweisen zu ermutigen, durch die der Workflow im Hinblick auf diese Limits gemanaged wird. Dadurch wird sich eine effektivere (d.h. weniger subjektive) Umwelt ergeben, in der es einfacher ist, die wirklichen Ursachen für Verzögerungen und schlechte Qualität aufzudecken und dann sinnvolle Änderungen durchzuführen und hinterher zu bewerten.

Aber es bleibt die Frage, ob wir es im Bereich der Computer-Netzwerke und in der Softwareentwicklung mit ebenso gleichförmigen und gleichmäßigen Szenarios zu tun haben wie in unserem Wasser-Beispiel? Und falls nein: Wie würden sich die Unterschiede auf Little’s Law auswirken? Bezogen auf die Softwareentwicklung kam mir sofort ein Gedanke: Wenn wir den WIP erhöhen, führt dies wahrscheinlich zu mehr Kontextwechseln (falls wir dem nicht durch explizite Regeln entgegenwirken). Und diese Kontextwechsel können bewirken, dass wir den Durchsatz nicht konstant halten können.
Dazu sehen wir uns noch einmal diese Darstellung von Little’s Law an:
LT = WIP / Durchsatz
Wenn es stimmt, dass ein erhöhter WIP zu mehr Kontextwechseln und somit zu einem niedrigeneren Durchsatz führt, dann haben wir es mit einem höheren Zähler und gleichzeitig einem niedrigeren Nenner zu tun. Wenn wir nun diese neuen Zahlen (als neue langfristige Durchschnittswerte) in Little’s Law einfügen, dann wird die Lead Time nicht mehr linear im Verhältnis zum WIP ansteigen. Noch einmal in Kurzform: Wenn wir bei einem erhöhten WIP den Durchsatz nicht konstant halten können, sondern dieser sinkt, dann werden wir beobachten, dass die Lead Time nicht-linear zum WIP ansteigt.

Zusammenfasung

Die Kernpunkte meiner E-Mail-Diskussion mit Arne lassen sich wie folgt zusammenfassen: 1) Es ist wichtig, sich darüber klar zu werden, auf welchen Annahmen Little’s Law basiert und was diese Annahmen für den jeweils betrachteten Kontext bedeuten. 2) Je nach Kontext kann sich aus Litte’s Law ergeben, dass die Lead Time linear oder eben auch nicht-linear ansteigt wenn wir den WIP erhöhen.
Wenn wir die zweite Darstellung von Little’s Law verwenden, dann müssen wir sicher gehen, dass wir es mit einem stabilen System mit langfristigen Durchschnittswerten für WIP und Durchsatz zu tun haben, bevor wir einen langfristigen Durchschnittswert für die Lead Time berechnen können. Wenn der Durchsatz konstant bleibt, während wir den WIP auf ein neues Niveau erhöhen, so wird die neue Lead Time sich proportional zum WIP erhöhen. Wenn allerdings der Anstieg des WIP mit einer Verringerung des Durchsatzes einhergeht (z.B weil es im Kontext der Softwareentwicklung zu mehr Kontextwechseln kommt), so wird die neue Lead Time im Verhältnis zum WIP nicht-proportional ansteigen.
In den nachfolgenden Tagen, nachdem ich dies hier aufgeschrieben hatte, wurde mir allerdings klar, dass es noch viel mehr zu Arnes ursprünglicher Frage zu sagen gibt. Ich hatte das Gefühl, dass wir auf den ersten Teil der Frage noch gar nicht tief genug eingegangen sind. Die dargestellten Punkte zu Little’s Law waren zwar sehr hilfreich für die Diskussion, aber sie beantworten immer noch nicht die Frage, warum in Computer-Netzwerken die Geschwindigkeit nicht-linear absinkt, sobald die Auslastung über 80% steigt. Im Nachhinein muss man wohl sagen, dass dieser Beitrag Arnes Frage gar nicht wirklich beantwortet hat. Also habe ich danach mehr und mehr darüber nachgedacht, wie und warum die drastische Absinken der Geschwindigkeiten von Computer-Netzwerken bei starker Auslastung zu erklären ist. Und noch wichtiger: Können wir daraus etwas über die Art lernen, wie wir unsere Policies erstellen und anpassen sollten, um unser System bei hohem WIP zu managen? Man kann sich denken, dass ich tiefer in dieser Frage eingestiegen bin und bereits einige interessante Dinge gelernt habe. Diese Dinge würde ich gerne aufschreiben und mit Anderen teilen. Aber dies gehört definitiv in einen zukünftigen Post

Alle Gute,
Frank

Anmerkung von mir (Arne Roock): Ja, es beantwortet meine Frage nur zum Teil. Aber das macht nichts, denn dieser Post beantwortet dafür eine ganze Reihe von Fragen von denen ich noch nicht einmal wusste, dass man sie stellen sollte! Danke, Frank! Und ich warte gespannt auf den angekündigten nächsten Post!




Kommentare:

  1. Hallo Arne,

    selbst wenn der Durchsatz konstant ist, hat man trotzdem eine nicht-lineare Beziehung zwischen Auslastung und Warteschlangenlänge. Little's Law sagt ja nichts zur Auslastung, weil es nur die Ankunftsrate betrachtet und nicht die Abarbeitungsrate. Um die Nichtlinearität zu verstehen, muss man die Abarbeitungsrate mit in Betracht ziehen.

    Beispiel:

    Bei einem Team kommen 8 Sachen pro Woche als neue Arbeit an. Das Team kann 10 Sachen pro Woche bewältigen, also ist es zu 80% ausgelastet (Auslastung = Ankunftsrate dividiert durch Abarbeitungsrate). Frage ich jetzt dieses Team, ob sie noch eine weitere Sache für mich tun können, dann werden sie mit 20% Wahrscheinlichkeit sagen: "ja, klar!". Mit 80% Wahrscheinlichkeit werden sie die neue Sache aber erst einmal in die Warteschlange legen und später erledigen.

    Was passiert, wenn man dem Team jetzt im Durchschnitt 9 Sachen pro Woche gibt? Die Auslastung steigt auf 90%. Die Wahrscheinlichkeit, dass sie noch eine weitere Sache sofort tun können, halbiert sich auf 10%. Neue Sachen landen also doppelt so oft in der Queue wie bei 80% Auslastung. Bei einer Steigerung auf 95% Auslastung ist es schon wieder doppelt so oft, bei 97,5% schon wieder doppelt so oft und so weiter. Bei 100% landet jede neue Arbeit in der Queue.

    Das alles passiert wohlgemerkt, selbst wenn(!) die Abarbeitungsrate konstant bleibt, was bei Menschen ja noch nicht einmal der Fall ist. Die Verhältnisse werden noch schlechter, wenn die Abarbeitungsrate wegen zu vieler Kontextwechsel sinkt.

    Also: Little's Law ist linear in Bezug auf Ankunftsrate. Die Warteschlangenlänge ist nicht-linear in Bezug auf Auslastung. Zwei verschiedene Dinge, zwei verschiedene Zusammenhänge.

    Schöne Weihnachten mit angemessener Auslastung wünscht Dir...
    Matthias

    AntwortenLöschen
  2. Achso, ich habe noch eins vergessen:

    Wir machen in der Softwareentwicklung etwas falsch, wenn wir annehmen, dass steigende Ankunftsrate auch steigende Abarbeitungsrate und damit steigenden Durchsatz bedeutet. Das gilt nur, wenn wir gleichzeitig das Team vergrößern oder den Prozess entscheidend verbessern. Deshalb ist es falsch, aus der ersten Form von Little's Law einfach so die zweite Form zu machen.

    Das ist der eigentliche, verblüffende Denkfehler, der den vermeintlichen Widerspruch zwischen linear und nicht-linear m.E. sofort erklärt.

    Nochmal schöne Grüße
    Matthias

    AntwortenLöschen
    Antworten
    1. Hallo Matthias,

      angenommen, wir haben ein WIP-limitiertes System. Dann können wir doch nur dann die Ankunftsrate erhöhen, wenn wir gleichzeitig die Abarbeitungsrate (=Durchsatz) erhöhen, oder?

      Viele Grüße,
      Arne

      Löschen
    2. Hallo Arne,

      das kommt darauf an, wo die Push-Pull-Boundary des Systems sitzt. Nehmen wir an, wir haben eine Scrumban-Umgebung, also normales Scrum plus ein WIP-limitiertes Kanban-Board. Dann sind PO und Team durch das Product Backlog getrennt: PO pusht hinein, Team pullt heraus. Die Ankunftsrate λ1, die der PO erlebt, sitzt vor dem Backlog, die Ankunftsrate λ2, die das Team erlebt, sitzt hinter dem Backlog. Der PO pusht mit λ1, das Team pullt mit λ2. Das Team arbeitet jedes Backlog-Item ab und stellt es mit einer Abarbeitungsrate μ fertig.

      Entsprechend hat dieses Team zwei Auslastungen: ρ1 = λ1/μ und ρ2 = λ2/μ. Über die erste Auslastung entscheidet der PO, über die zweite das Team (wenn es starkes Selbstbewusstsein hat).

      Wir hatten gesagt, das Team arbeitet WIP-limitiert auf einem Kanban-Board. Damit kann λ2 schon mal nicht größer als μ werden, da hast Du recht. Das Team lastet sich selbst also vielleicht zu ρ2=85% aus (λ2 = 0,85μ). Der PO kann aber viel schneller pushen, λ1 kann bei 99% von μ liegen oder sogar größer als μ werden (damit wird ρ1>100%). Dadurch wächst das Backlog immer weiter an, das Team wirkt nach außen "überlastet", es "schafft" nicht genug, obwohl innen ein sauber koordiniertes, entschlossenes Arbeitsklima herrscht und das Team sein Bestes tut.

      M.E. ist es der Job eines guten PO, diese Situation zu erkennen, λ1 zu begrenzen und den Business-Wert der Backlog-Elemente zu maximieren, um möglichst viel Euro aus dem zur Verfügung stehenden μ zu holen. Alternativ kann er auch λ1 gleich lassen und alle paar Wochen das halbe Backlog wegwerfen, doch das wird ihm nicht gefallen. :-)

      Schöne Grüße,
      Matthias

      Löschen
    3. Hi Matthias,

      die von dir beschriebene Realität und deine Ausführungen sind richtig, und sie zeigen gut, warum das Team sich nur auf den Bereich committen sollte, den es unter Kontrolle hat - und das ist eben ein WIP-Limiterter Teilbereich der gesamten Wertschöpfungskette.
      Aber ich gebe dir Recht: Die Realität sieht meistens anders aus.

      Viele Grüße,
      Arne

      Löschen