Work in Progress (WiP)

Heute schauen wir uns das Work in Progress Limit (WiP-Limit) an, welches aus dem KanBan stammt.

Work in Progress (wiP) - Du kannst genau eine Sache gut! - Team arbeitet an einem Laptop gemeinsamWork in Progress Limits sind einigermaßen banal, nicht immer leicht umzusetzen und wahrscheinlich auf Grund ihrer Einfachheit so mächtig.

Wir lieben sie jedenfalls und möchten dieses Thema auch Dir näherbringen. Hoffentlich hast auch Du einen Aha-Effekt dabei!

Diese Folge auf YouTube: https://youtu.be/_Ddcbu98k9o

Abkürzung

Du hast es sicherlich schon gemerkt: Die Abkürzung für Work in Progress ist WiP. Wir Agilisten sprechen daher auch gern über WiPs oder WiP-Limits. Ja lässt sich leicht mit VIP und vielleicht einem HIPPO verwechseln.

Wie viel Arbeit kannst Du gleichzeitig machen?

Bei Work in Progress Limits geht es darum gleichzeitige Arbeit zu limitieren. Wie viel Dinge kannst Du gleichzeitig tun?

Genau eins.

Alles andere ist eher sequenziell für Dein Gehirn und oft ist es so, dass wenn wir glauben mehrere Dinge gleichzeitig tun zu können, dass wir beide eher schlechter machen und dafür länger brauchen. Beispielsweise YouTube schauen und gleichzeitig Instagram bedienen. Dein Gehring braucht auch länger und mehr Energie zum Umschalten zwischen beiden Themen. Bei 3 oder mehr Aufgaben wird es sogar noch schlimmer und die Verlustleistung zum Umschalten oder verlorenen Informationen erhöhen sich.

Das Limit eines Menschen liegt also bei Eins.

Prozess abbilden

Die Limits selbst findest Du nun über den Spalten Deines Kanban-Boards. Auf diesem Board ist Dein jeweiliger Prozess im Team abgebildet. Hast Du also beispielsweise die Phasen Programmieren, Review, Kompilieren, Testen und Release, dann sind das Deine Spalten. Die Work in Progress Limits stehen nun darüber und zeigen an wie viele Tickets gleichzeitig in der jeweiligen Spalte sein dürfen.

Ist eine Spalte voll, so kann in diese kein weiteres Ticket nachgezogen werden. Du erinnerst Dich vielleicht. Grundlage ist hier der Wechsel vom Push zum Pull-Prozess. Die Arbeit wird also nachgezogen und durch das WiP-Limit begrenzen wir die Arbeit im jeweiligen Prozessschritt. Im Pull Prinzip bauen wir die Lieferkette vom Ende aus auf und ziehen uns immer wieder die Arbeit aus dem vorhergehenden Prozessschritt. So können wir auch den 7 Arten der Verschwendung entgegenwirken und vermeiden beispielsweise große Lagerhaltungskosten.

Doch wozu das Ganze?

Hört sich vielleicht paradox an, doch wir machen das um absichtlich Flaschenhälse im Prozess zu haben und so eventuelle Schwächen zu finden und den Prozess so gemeinsam zu verbessern. Das Ganze natürlich möglichst früh, daher auch gern enge Limits einführen.

Regeln sind da um eingehalten zu werden

WiP-Limits bringen Dir gar nichts, wenn sie über Bord geworfen werden, sobald es mal etwas eng wird.

Die Zubettgehzeit wird nicht verhandelt, wenn Zubettgehzeit ist.

Wenn euch das Limit stört, dann habt ihr Retrospektiven dafür um diese dann in Ruhe und konzentriert anzupassen. Oder vielleicht sogar euren gesamten Prozess.

Diese Limits bringen also nur etwas, wenn sie auch eingehalten werden. Kann Dein Team dies nicht, dann lasst sie lieber weg.

Die Einführung

Janina Kappelhoff würde bei der Einführung von Work in Progress Limits immer mit einer Spalte im Prozess anfangen. Henry Schneider dagegen würde die Limits auf alle Spalten verteilen und in Summe maximal die Hälfte der Entwicklerkapazitäten vergeben. Bei 6 Entwicklern also in Summe ein Limit von 3.

Janina führt es gern erst ein, wenn Schmerz aufgetreten ist. Henry dagegen gern als viertes. Hintergrund bei Janina ist der, dass sie gern nur Dinge einführt, die das Team braucht. Dann auch nur in dieser einen Spalte. Henry führt Work in Progress Limits gern früh ein um auch schnell den Prozess zu optimieren, bevor dieser in ein IT-Tool gegossen wird und dann nur noch schwer zu verändern ist.

Spalte voll und nun?

Und wird wahrscheinlich eine Beobachtung sein, dass jetzt meine Spalte vollläuft, weil die nachfolgende nichts zieht. Habe ich dann jetzt Langeweile? Nein, denn jetzt geht es los den anderen im Team zu helfen. Erst einmal haben wir einen Flaschenhals identifiziert, der Prozess kann also optimiert werden. Gleichzeitig können wir jetzt Effekte wie Problem Swarming oder Crossfunktionalität nutzen und damit die Arbeit schneller erledigt bekommen.

Genau hierin liegt die Magie von WiP-Limits.

Personen-WiPs

Personen WiPs macht Henry zwei unterschiedliche Dinge. Zum einen bekommen manchmal Einzelpersonen ein WiP-Limit, vor allem wenn sie in mehreren Projekten unterwegs sind, damit sich deren Product Ownerinnen und Chefs darüber einigen müssen, wie die Arbeit verteilt wird, und nicht die Person selbst priorisieren muss. Ich verlagere daher die Verantwortung.

Die zweite Sache, wie ich es benutze ist, dass gerade bei der Einführung von Agilität und vor allem wenn wir ein NoEstimation Team haben, dass dieses WiP-Limit im Planning von Personenzahl/2 bekommt. Schaffen sie dann alles, dann dürfen sie im nächsten Sprint eine User Story mehr ziehen und umgekehrt. So pendelt sich die Anzahl der Stories irgendwann ein.

 

Get shit done,

Janina & Henry


Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.


Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉

Auf der Znip Academy Seite findet Du auch viel nützliches Wissen zu Scrum und Agilität und die passenden Trainings dazu. Falls nicht, frag uns einfach an.


Janinas Ultimativer OKR Guide


In der Podcastfolge erwähnte Folgen zur Vertiefung:


Connecte dich gerne hier mit uns:

LinkedIn

Instagram

YouTube

Facebook

Webseite

Facebook-Gruppe