Kanban konzentriert sich auf den Arbeitsfluss. Indem euer Team die gesamte Arbeit auf dem Kanban-Board sieht, weiß es, was gerade passiert, welche Aufgaben feststecken und welche vorankommen. Damit euer Team mit Kanban erfolgreich arbeitet, muss die Menge der Aufgaben auf dem Board jedoch begrenzt sein.
Arto Kiiskinen
Arto is a Leading Product Owner Coach with 20 years of experience in leading R&D activities both in large and small organizations, in many different roles. He is now committed to training and coaching product owners to become better at their work. He is also CSPO, PSPO, PSM, and ISTQB certified.
Das bezeichnet Kanban als Work-in-Progress-(WIP-)Limits, und sie sind für gutes Kanban wirklich unverzichtbar.
Ein Team kann beispielsweise gleichzeitig nur fünf Aufgaben in der Entwicklung oder drei Aufgaben im Test haben. Ist das WIP-Limit erreicht, sollte das Team keine Arbeit in den nächsten Prozessschritt verschieben dürfen, bis die Phase, die den Fluss begrenzt, entlastet wurde.
Das Chaos ohne WIP-Limits
Ohne WIP-Limits kann sich in eurem Team schnell zu viel laufende Arbeit ansammeln. Bei zu vielen Aufgaben auf dem Board:
wird es schwierig, den Arbeitsfluss vorherzusagen oder zu steuern.
kommt es häufig zu Aufgabenwechseln und mehr Stress.
Das Team ist gezwungen, Mechanismen zu entwickeln, um dringende Arbeit durch einen ansonsten verstopften Prozess zu schleusen. Das kann zu einer Priorisierung nach dem Motto „Wer am lautesten schreit, gewinnt“ führen – und genau dieses Verhalten solltet ihr dem Rest der Organisation nicht vermitteln.
Die meisten Kanban-Teams setzen jedoch keine strikten WIP-Limits. Und Teams, die sie einführen, halten sie oft nicht ein.
Stellt euch statt eines Softwareentwicklungsprozesses eine Fabrikhalle vor
Stellt euch eine andere, traditionellere Art von Arbeit vor: eine kleine Fabrikwerkstatt, die physische Produkte herstellt. Die Produkte würden an mehreren Arbeitsstationen gefertigt. Die Schritte könnten sein:
Bearbeitung
Lackierung
Montage
Abschließende Qualitätsprüfung
Stellt euch vor, in der Endmontage tritt ein Problem auf. Die Produktionslinie muss aus irgendeinem Grund angehalten werden. Ursache könnten Fehler an Komponenten aus vorgelagerten Prozessschritten oder ein Ausfall der Werkzeuge an der Produktionslinie sein. Was würde in der Fabrikhalle passieren?
Ich bin mir ziemlich sicher: Wenn das Problem länger als ein paar Minuten bestehen bliebe, würden die Mitarbeiter an den Lackier- und Bearbeitungsstationen davon erfahren. Würden sie an ihren Stationen normal weiterarbeiten und die Fabrikhalle mit halbfertigen Komponenten füllen?
Das wäre ziemlich absurd. Es wäre völlig unsinnig, in den vorherigen Schritten weiterzuarbeiten, wenn die Arbeit in den nachgelagerten Schritten nicht weiterfließt. Es wäre sogar physisch unmöglich – in der Fabrikhalle gäbe es keinen Platz, um die unfertigen Komponenten zu lagern.
Wenn möglich, würden die Mitarbeiter sicher versuchen, die Produktionslinie so schnell wie möglich zu analysieren und zu reparieren.
Warum funktioniert derselbe gesunde Menschenverstand bei Kanban in der Softwareentwicklung nicht?
In der Softwareentwicklung sind Arbeitselemente nicht physisch. Tritt in den nachgelagerten Arbeitsschritten ein Problem auf, wird der Platz im Büro dadurch nicht weniger. Entwickler können die Arbeit weiterhin in den nächsten Prozessschritt verschieben.
Genau deshalb gibt es Kanban-WIP-Limits. Sie sind virtuelle Einschränkungen, die Prozessengpässe sichtbar machen sollen. Wenn ihr sie vollständig ignoriert – oder gar keine WIP-Limits habt –, verhaltet ihr euch wie die unaufmerksamen Fabrikarbeiter, die die Fabrikhalle blind mit unvollständiger Arbeit füllen.
Warum lassen sich WIP-Limits bei IT-Arbeit leichter ignorieren? Das könnte folgende Gründe haben:
Arbeitstickets sind abstrakter als physische Objekte.
Wir verstehen oder respektieren nachgelagerte Arbeit nicht wirklich.
Wir arbeiten nicht als Team und konzentrieren uns nur auf unseren eigenen Prozessschritt.
Wir messen den Workflow nicht mit DevOps-Metriken wie der Durchlaufzeit.
Wir wollen instinktiv „effizient“ sein und bei der Arbeit beschäftigt wirken.
Widersteht dem Bedürfnis, „effizient“ wirken zu wollen.
Effizienz ist ein Maß für Situationen, in denen ihr mit verbundenen Augen arbeitet. Wenn ihr nicht wisst, wie die Arbeit den Prozess des Teams durchläuft, konzentriert ihr euch natürlich darauf, eure eigene Aufgabe möglichst schnell und effizient zu erledigen.
Vielleicht habt ihr den Instinkt, „effizient und beschäftigt“ zu sein. Was tut ihr, wenn ein Vorgesetzter in der Nähe ist? Alle tun so, als wären sie beschäftigt! Ist dieses Verhalten darauf zurückzuführen, dass wir als wertvoller Teil des Teams wahrgenommen werden wollen?
Was ihr tun könnt, um die Situation zu verbessern
Wie können wir dem Team den Wert eines guten Arbeitsflusses und der Begrenzung paralleler Arbeit vermitteln? Ich denke, wir sollten:
Den Arbeitsfluss bis „Done“ messen und mit strikten WIP-Limits experimentieren
Maßnahmen ergreifen, um die Auswirkungen von Einschränkungen und Engpässen zu verringern
Andere Arbeitsschritte besser kennenlernen – Rollen wechseln
Teambuilding – lernt euch kennen, dann werdet ihr eher helfen wollen, wenn andere Teammitglieder Unterstützung brauchen
Den Arbeitsfluss bis „Done“ messen
Der Scrum Master könnte die wöchentliche Velocity des Teams messen. Sie könnte beispielsweise jeden Freitag berechnen, wie viele Tickets es in dieser Woche in die Spalte „Done“ geschafft haben. Anschließend könnte sie mit dem Team ein Experiment vereinbaren: In der folgenden Woche hält sich das Team strikt an festgelegte WIP-Limits. Am Freitag wird dann erneut gemessen, wie viel Arbeit erledigt wurde.
Das Team sollte anschließend besprechen, wie die WIP-Limits für die nächste Woche angepasst werden können. Ich garantiere euch: Das wird die Dinge beschleunigen. Es ist unvermeidlich. In Kombination damit, Arbeit in kleinere Einheiten aufzuteilen, sollte dieser Ansatz in jedem Rezeptbuch für „Kanban-Meister“ stehen.
Engpässe erkennen
Das Team hat einen Engpass. Jeder Prozess auf der Welt hat einen, und das Team auch. Was ist es? Das Testen? Automatisierte Tests? Die Freigabe durch den Kunden? Der Scrum Master des Teams muss diese Frage stellen, und das Team muss sich des Engpasses bewusst sein.
Die nächste Frage lautet: Wie kann der Arbeitsfluss durch den Engpass erhöht werden? Zum Beispiel:
Wenn der Engpass bei automatisierten Tests liegt: Wie können Erstellung und Ausführung der Tests beschleunigt werden?
Wenn der Engpass bei Code Reviews liegt: Welche Regeln kann das Team festlegen, um das Reviewen der Pull Requests anderer Entwickler schneller zu machen?
Den Gesamtprozess besser verstehen
Wenn das Problem mit zu viel WIP darin besteht, dass das Team andere Schritte im Prozess nicht kennt oder nicht respektiert, ist es vielleicht Zeit für einen Rollenwechsel. Lasst Entwickler eine Zeit lang testen und Tester mit einem Entwickler im Pair Programming arbeiten.
Ich bin außerdem fest davon überzeugt, dass klassisches „Teambuilding“, bei dem sich die Teammitglieder besser kennenlernen, auch dabei hilft, die anderen stärker zu respektieren. Seid ihr eine Gruppe oder ein Team? Sprecht über andere Dinge als die Arbeit und lernt die Person hinter der Rolle kennen.
Ich hoffe, dieser Blog hat euch dazu angeregt, WIP-Limits mit eurem Team durchzusetzen. Viel Erfolg beim Begrenzen paralleler Arbeit!
- Softwareentwicklung
- Produktmanagement
Subscribe to our newsletter
Related blogs
