Warum gilt die WIP-Grenze für eine Kanban-Disziplin für abgeschlossene Arbeit?

In Kanban gibt es eine harte Work-in-Progress-Grenze, die verhindert, dass eine Disziplin an zu viel auf einmal arbeitet. In dieser beispielhaften Kanban-Tafel umfasst das WIP-Limit die in der Spalte „erledigt“ aufgeführte Arbeit.

Warum kann beispielsweise die Analysedisziplin, die eine ihrer Aufgaben abgeschlossen hat, nicht eine andere Aufgabe aus der Spalte Weiter ziehen und mit der Bearbeitung beginnen? Was ist, wenn die Analyse alle Arbeiten erledigt, die Entwicklung aber immer noch keine Arbeit leisten kann? Sollen sie aufhören zu arbeiten?

Das scheint keine effiziente Arbeitsweise zu sein. Sie können sagen: „Das Management sollte sicherstellen, dass die Entwicklung den Fluss nicht aufhält“, aber wenn dies zum ersten Mal auftritt, wird das Management die Analyse bitten, das WIP-Limit zu überschreiten, während es versucht, die Entwicklung zu verbessern, und nicht die Tools herunterzufahren Halten Sie an einem idealen Prozess fest.

Antworten (6)

WIP-Limits sollen Engpässe anzeigen, damit das Management sie BEHEBEN kann.

Wenn das Limit im „Fertig“-Bereich erreicht wird und die Upstream-Leute immer noch weitermachen können, als wäre nichts passiert, weiß das Management möglicherweise nichts davon, weil es nicht mehr offensichtlich ist.

Der eigentliche Akt des „Aufhörens der Arbeit, weil ich das Limit erreicht habe“ ist der Mechanismus, der den Benachrichtigungsprozess auslöst.

Ja, es ist umständlich. Aber es funktioniert. Viele Leute sprechen nicht gerne über Verzögerungen im Arbeitsablauf, weil sie denken, dass dies ein schlechtes Licht auf sie wirft, oder weil sie dieses „jammernde Schnatz“-Tag nicht mental ablegen können, das WIP-Limit nimmt es ihnen aus der Hand.

Langfristig werden Ihre Teambeziehungen weniger belastet, weil es nicht mehr persönlich ist, sondern nur noch das blöde Board. :-P

Ich verstehe: Es ist ein Feature, kein Fehler, dass die Analysten die Arbeit eingestellt haben, und nicht die Arbeit, die sich vor den Entwicklern staut.
Ihre Antwort gefällt mir, aber ich bin mir definitiv sicher, dass das Management nicht alle Engpässe beheben sollte. Ich würde sagen, wenn die Teammitglieder aufgrund einiger externer Abhängigkeiten einen Engpass nicht selbst beheben können, sollte das Management einspringen und aushelfen. Es ist wichtig, Mikromanagement zu vermeiden
Ja, im Fall von funktionsübergreifenden Teams ist es meiner Erfahrung nach besser, es im Team zu belassen, es sei denn, Sie haben am Ende mehr als einen Engpass. Das ist normalerweise ein Zeichen dafür, dass das Team nicht damit fertig wird. Bei einzelnen Engpässen ist der Teamleiter normalerweise ausreichend in der Lage, das Problem zu lösen, es sei denn, es geht um Zahlen.
@tenpn, versuche es nicht als "Arbeitsstopp" zu betrachten. Es ist eher eine "Ich muss das reparieren oder jemanden dazu bringen, es zu tun, wenn ich es nicht kann". Es ist im Grunde so, als würde man ein wenig Produktion im Voraus bezahlen, um für den Rest einer laaaangen Reise einen reibungsloseren Arbeitsablauf zu erhalten.
Sie sollten immer zuerst von allem arbeiten, was Sie auf der rechten Seite des Bretts tun können. Wenn Ihre Analysten wegen eines Engpasses in der Entwicklung aufgehalten werden, gibt es irgendeine QA-Arbeit, bei der sie helfen können? Können sie sich mit einem Entwickler zusammensetzen und ihm helfen, ein Problem zu lösen? Sind sie eigentlich nur fertig, weil sie den Entwicklern beschissene Anforderungen stellen, die die Entwicklung verlangsamen? Es ist vielleicht nicht die Schuld der Entwickler, dass die Arbeit in ihrer Abteilung zu Engpässen führt!

Mir wurde ein großartiges Spiel beigebracht, das dieses Konzept wirklich betonte. Es ist das Papierflugzeug-Produktionsspiel. Was es brutal zeigt, ist Verschwendung, wenn etwas Unerwartetes passiert.

Angenommen, Sie bauen fünf Flugzeuge für einen Kunden. Betrachten wir zwei Szenarien. In beiden Fällen werden Sie bezahlt, wenn jedes Flugzeug produziert wird. Sobald ein Flugzeug zum Kunden geht, werden Sie für dieses Flugzeug bezahlt.

1- Sie bauen sie im klassischen Stil. Aus irgendeinem Grund dauert der Zusammenbau des Cockpits ewig. Sie bekommen ein Flugzeug geliefert und vier weitere sind bis auf die Cockpits fertig. An diesem Punkt entscheidet der Kunde, dass er diese Flugzeuge nicht wirklich will und kündigt den Vertrag. Die Stornogebühr deckt nicht einmal ansatzweise die Kosten für die vier teilweise gebauten Flugzeuge und die verlorenen Arbeitsstunden. Hoffentlich finden Sie bald einen weiteren Kunden.

2- Sie bauen jedes Flugzeug unter Kanban. Aufgrund der Verzögerung in der Cockpitkonstruktion haben Sie nur ein Flugzeug in Produktion, wenn der Kunde die Bestellung storniert. Die Stornogebühr deckt die Kosten für dieses eine Flugzeug, und wenn Sie es schaffen, das Flugzeug bald zu verkaufen, haben Sie am Ende die Nase vorn.

+1 Wenn ich eine Antwort favorisieren könnte, würde ich diese favorisieren. Das ist eine wirklich gute Metapher.

Es scheint keine effiziente Arbeitsweise zu sein, da wir alle darauf trainiert wurden, dass wir alle so nah wie möglich an 100 % der Zeit ausgelastet sein sollten.

In dem von Ihnen gegebenen Beispiel ist es nicht wünschenswert, dass Ihre Analysefunktion die Arbeit über das WIP-Limit hinaus abschließt, da Sie eine Arbeitswarteschlange erstellen, mit der die Entwickler nicht Schritt halten können. Diese Warteschlange wird weiter wachsen und die Analyse veralten.

Es ist viel besser, wenn der Analyst bei der Entwicklung, der Qualitätssicherung, der Durchführung von Demos oder anderen Arbeiten hilft, die dazu beitragen, vorgelagerte Blockaden zu beseitigen und die Arbeit über den gesamten Workflow hinweg zum Fließen zu bringen, nicht nur für ihren Teil des Prozesses.

tl;dr WIP-Limits ermutigen zur Optimierung des Systems, nicht nur eines Prozessschritts.

Sie sagen, dass dies keine effiziente Arbeitsweise zu sein scheint. Denken Sie daran, dass Kanban nicht dazu da ist, die Arbeit jedes Einzelnen zu optimieren. Vielmehr dient es der Optimierung des Gesamtdurchsatzes des Systems. Manchmal bedeutet das, dass eine Person anhalten und/oder einem anderen Team helfen muss, anstatt eine andere Aufgabe zu erledigen.

Die Done-Spalte ist, wie Sie schon sagten, begrenzt, damit der Fluss weiter fließt: Die Kollegen sollen aus der zweit-, dritt-, letzten Done-Spalte von rechts ziehen. Das Ziel ist es, einen geringeren Lagerbestand zu haben, Überproduktion zu vermeiden und Wert zu liefern. Abgeschlossene Analysearbeit hat keinen Wert, bis sie implementiert ist.

Wenn die Analysedisziplin mehr Arbeit erledigt als die Entwicklung, dann gibt es ein Problem mit der Organisation:

  • entweder stimmt was mit der entwicklung nicht, oder
  • das Geschäft braucht nicht so viel Arbeit zu erledigen

Das gesamte Done+Pull-Konzept in Kanban entstammt dem Just-in-Time- Prinzip.

Andererseits bin ich mir nicht ganz sicher, ob das Management eingreifen sollte, bis die Organisation nicht weiß, wo das Problem liegt. Vielleicht ist die Entwicklungsabteilung langsam, oder sie hat Test-/Umgebungsprobleme, oder sie ist einfach zu klein.

Ich mag das Just-in-Time-Ding. Es ist keine wertvolle Arbeit, wenn die Möglichkeit besteht, dass es neu gemacht werden muss oder es von Arbeitern weiter unten im Strom nicht verwendet wird.
Oder die Entwicklung wird behindert, weil die Analyse eigentlich nur schnell Müll vervollständigt, mit dem die Entwickler nicht arbeiten können.

Zusätzlich zu den anderen großartigen Antworten hier möchte ich hinzufügen, dass die Analyse nicht zu weit im Voraus erfolgen kann. (Obwohl die Grenze von 2 und 3 etwas niedrig erscheint)

Wenn das der Fall wäre, wäre das Projekt eher ein Wasserfall und weniger agil. Wasserfall und Kanban vertragen sich nicht sehr gut.

Warum gilt die WIP-Grenze für eine Kanban-Disziplin für abgeschlossene Arbeit?
AntwortenHierDatenschutz-Bestimmungen1y, 0v