Wenn ich Scrum-Teams oder allgemein agile Teams betreue stelle ich immer wieder fest, dass es von aussen eine gewisse Erwartungshaltung gibt, einzelne Prozessschritte zu optimieren. Dazu habe ich folgende Geschichte…die im Dezember letzten Jahres in der USA-Today stand:

Es ist die Geschichte von Flippy, dem Burger- Wende Roboter, der von Cali-Burger in Kalifornien eingeführt wurde. Was war passiert? Die Cali-Gruppe – also der Betreiber der Burger-Restaurants, hatte Schwierigkeiten, die Mitarbeiter in der Küche zu halten. Cali verkauft Hamburger nach „Southern California-style“ für $3,99. Der Markt ist umkämpft, die Margen gering und die Löhne dementsprechend. Es verwundert also nicht, dass die Leute, die bei Cali arbeiten nur mäßig Erfüllung in ihrem Job finden. 

„Wir bilden sie aus, sie arbeiten am Grill, sie merken, dass es keinen Spaß macht … und so gehen sie und fahren Uber“, sagt John Miller, CEO der Cali Group.

Die Lösung lag also auf der Hand – ein Roboter sollte es richten:

In einer Stunde könnte das Gerät bis zu 150 Burger bearbeiten – was an einem Tag ca. 2000 Hamburger bedeutete und so könnte er bis zu 50 Mitarbeiter ersetzen, so die Planung der die Restaurantkette und des Herstellers Miso Robotics.

Doch nach nur zwei Tagen wurde Flippy erstmal vom Dienst suspendiert. Allerdings lag das wohl auch auch am starken Andrang in dem Restaurant in Pasadena in dem die Kette den ersten Roboter einsetzte. Die Leute waren halt doch zu neugierig.

Allerdings war der Roboter ja nur ein Roboter – und wie wir wissen sind Computer ja bekanntlich „Doof“. Flippy war vor allem deshalb zum Flop geworden, weil er miserabel mit seinen menschlichen Kollegen zusammengearbeitet hatte, „Es geht ums Timing“, sagte in dem Zeitungsartikel  Cali-Technik-Chef Anthony Lomelino. „Alle müssen ihren Arbeitsrhythmus an Flippy ausrichten.“ 

Normalerweise kommunizierten die Leute ständig untereinander und stimmten so die Arbeitsgeschwindigkeit aufeinander ab, das war mit Flippy nicht möglich – die Schnittstelle zum Grill – also das Vorbereiten der Burger-Patties und das Belegen der Brötchen mit Salat – wurde zum Problem. Und so war es insgesamt nicht möglich einen kontinuierlichen Arbeitsfluss sicherzustellen und erst recht nicht, eine den Output an Burgern zu erhöhen. 

Die Restaurantkette will wollte dann ihre Mitarbeiter besser für die Zusammenarbeit mit dem in sozialen Dingen unfähigen Roboter trainieren. Erst dann sollte dieser wieder den Arm um seine sechs Achsen kreisen lassen um die Burger Patties zu flippen….also umzudrehen

Was aus Flippy bis heute wurde, kann ich nicht sagen. Aber das ist ein gutes Beispiel dafür, wie der Ansatz in einem Workflow einzelne Workflowschritte zu optimieren dafür sorgen kann, dass die Performance des gesamten Workflows sogar sinkt. Und diese Erkenntnis ist nicht neu – es ist sogar die Regel.

Und das liegt letztlich daran, dass zu viel Arbeit im System ist. Mit lokalen Optimierungen wird dafür gesorgt, dass an einzelnen Stellen noch mehr Arbeit ins System gepumpt wird, so dass der Durchsatz im Gesamtsystem sogar sinkt. Erinnere Dich nochmal an das Beispiel mit den Einkaufswagen aus der letzten Folge: Der Supermarkt kann nur eine begrenzte Anzahl von Kunden verkraften – sonst sinkt der Umsatz pro Person oder – wie aktuell – es steigt das Infektionsrisiko in Coronazeiten…

Die Lösung liegt also in einer Limitierung der Arbeit, die sich im System befindet. 

Um die Arbeit im System zu limitieren gibt es mehrere Möglichkeiten – eine weit verbreitete ist einfach die Limitierung der Arbeit in jedem einzelnen Workflowschritt. 

Ich hatte ja in der letzten Folge schon über Push und Pull gesprochen – in Kanban wird nach dem Pull Prinzip gearbeitet -und in Scrum sollten wir das übrigens auch tun- wird nur oft vergessen. Also pull bedeutet ja – ich lasse meine Sachen auf meinem Schreibtisch, bis sie der nächste abholt – wenn mein Schreibtisch voll ist, kann ich nicht mehr weiter arbeiten…Push war – ich packe meine fertigen Dinge auf den Schreibtisch des Nächsten und kann so immer weiter machen, auch wenn der nächste bereits überlastet ist. Je nachdem wie hoch der Stapel bei ihm ist – er wird ja nicht schneller arbeiten können, wenn er die Qualität halten will – wird es bei ihm ewig dauern, bis die Dinge, die ich ihm eben gerade gegeben habe abgearbeitet sind, weil da ja noch die Dinge liegen, die ich da gestern hingegeben habe und vorgestern und vorvorgestern…

Wenn wir in einem Pull-System mal überlegen was passiert, dann fällt uns auf dem Kanban-Board etwas auf: wir arbeiten von rechts nach links!

Also wenn wir mal mit unserem geistigen Auge auf das Board schauen..stell Dir das mal jetzt mal so bildlich vor: jeder der Arbeitsschritte kann nur starten, wenn der nach ihm laufende Prozessschritt fertig ist, damit wir keinen Waste – also “Verschwendung” produzieren – also wenn wir nicht mit unfertigen Dingen unser System vollstopfen. D.h.nach dem letzten Schritt – also der Fertigstellung eines – ich nenne es mal “Teils” wird das nächste Teil vom vorletzten Workflowschritt genommen, was wiederum ermöglicht ein Teil vom vor-vor-letzten Arbeitsschritt zunehmen und so weiter. Wir arbeiten also sozusagen von hinten nach vorne. Wir ziehen quasi die Arbeit hinten aus dem System raus und schaffen so Platz für Neues.  Ein beliebter Begriff dafür ist “Stop starting, start finishing”. Es macht als keinen Sinn immer nur neue Sachen zu starten und keine fertigzustellen. Wir beenden erst eine Aufgabe, bevor wir eine neue anfangen. Also wir dürfen oder können gar nichts beginnen, wenn wir nicht vorher etwas fertig gestellt haben. 

Ich wiederhole mich…glaube ich…

Seltsamerweise erlebe ich das andersrum aber sehr oft. (und kann das auch gut nachvollziehen, denn ich denke, wir alle kennen das Gefühl, dass man Dinge beginnt und irgendwie nichts fertig bekommt. Es scheint also irgendwie in unserer Natur zu liegen, mehr anzufangen als abzuschließen. Vielleicht liegt es ja auch daran, dass man geschäftig wirken will und den Kunden beruhigen will mit den Worten: “wir haben schon angefangen”…klingt ja auch besser als – “das liegt noch im Backlog”   Doch wohin führt dies?

Wenn wir uns einen Flughafen vorstellen, an dem immerzu Maschinen landen aber keine mehr abheben, dann ist der in kürzester Zeit überall mit Flugzeugen vollgestellt. (Ich spreche jetzt natürlich von Zeiten, als wir noch Luftverkehr hatten – aktuell – also bei Aufnahme dieses Podcasts – leben wir ja noch in der Corona-Phase und da passiert auf den Flughäfen ja eher gar nichts…)

Aber komme ich mal zurück: kannst Du dir vorstellen, wie lange es braucht bis ein Teil durch einen Engpass geht? Ich hatte mal einen Kollegen, der hat seine Arbeit in Form von Stapeln auf seinem Schreibtisch strukturiert… diese Stapel erreichten teilweise höhen von 40-50cm – also ein halber Meter Papier – das war echt schwer, der Schreibtisch bog sich schon fast. Er war ständig überlastet und wurde nicht fertig….Und es ist ja nicht so, dass an den Dingen, die auf seinem Schreibtisch lagen gearbeitet wurde – die lagen halt nur da…es handelte sich meist um Konzeptpapiere, die irgendwie fertig gestellt werden mussten für kleine Anforderungen oder Störungstickets für Fehler im System (die meist nicht kritisch waren, denn die kritischen wurden ja schon vorrangig behandelt.) 

Klaus Leopold, der große Meister und in nenne ihn mal “Guru” des Kanbans im deutschsprachigen Raum hat in seinem Buch “Kanban in der Praxis” das mal schön aufgezeigt. Er hat – um sowas mal sichtbar zu machen –  beispielhaft mit einem Team ein Board erstellt mit zwei Schwimmbahnen (also diesen Swimlanes) – eine für die Dinge, die wirklich gerade in Arbeit sind („aktive Arbeit“ genannt) und eine mit den Dingen, die auf irgendwas warten (das war dann die Swimlane „inaktive Arbeit“) – also in einem unlimitierten System mit Engpässen. Und wenn jemand eine Karte bearbeitet hat, dann wanderte die von inaktiv in aktiv und wenn er wieder was anderes gemacht hat , wanderte die Karte wieder zurück in inaktiv…und dabei stellte sich auch heraus, dass sich einige Karten quasi nie von inaktiv zu aktiv bewegten  – einige waren auch durch andere Dinge blockiert und konnten sich gar nicht bewegen. Und er hat mal ausgerechnet, wie lange es dauert, bis eine Aufgabe bzw. eine “Karte”   da so durch geht…Das Ergebnis ist total beeindruckend, denn wir haben ja irgendwie die Vorstellung, dass – wenn etwas in arbeit ist – dass sich dann auch etwas fortbewegt. Aber weit gefehlt – der Stillstand lag bei 98,6%.  Also nur 1,4% der Karten wurden gerade bearbeite und die anderen lagen unbeachtet rum. Du siehst…unlimitierte Systeme hören irgendwann auf zu fließen…und nähern sich dem Stillstand – je mehr Arbeit wir in das System stecken, desto langsamer wird es…

Es geht also nicht darum schneller zu arbeiten, sondern schlauer zu arbeiten.

Und dafür brauchen wir die Limits also die Beschränkung der aktuell in Arbeit befindlichen Dinge. Also die WIP-Limits.

Aber wie Du Dir vorstellen kannst – die Argumentationskette macht hier oft Probleme. Wenn wir uns einen Arbeitsprozess vorstellen und den in einem Workshop an der Wand transparent machen, dann sehen wir – und es ist dann nicht mehr zu übersehen – wo sich die Karten häufen – also wo ein Engpass vorliegt. Leider reagiert hier ein handelsübliches Management bzw. die Führungsebene meist mit einer Erhöhung des Drucks auf diese Situation – also wenn es irgendwo klemmt, dann muss ich nur fest genug drücken bis der Pfropfen durch das Rohr geht…Mit der Logik ist die vermeintliche Lösung: wenn zuviel Arbeit da ist, dann müssen wir eben mehr arbeiten! Das kann dazu führen, dass die Mitarbeiter Überstunden machen oder dass sogar noch neue Leute eingestellt werden – oder Task-Forces ins Leben gerufen werden, damit dieser entstandene Berg endlich mal abgearbeitet werden kann. 

…Leider geht das nicht! Das funktioniert nicht…Die Lösung liegt darin, Druck herauszunehmen – das weiß schon die Physik, also die Arbeit zu limitieren, die im System steckt. Und das – hier wieder ein weit verbreitetes Missverständnis – erreichst Du, in dem du die Arbeit, die im System steckt beschränkst – das heißt nicht, dass Du weniger arbeiten sollst. 

Also – die Einführung von WIP-Limits bedeutet nicht, dass Dein Team nun weniger arbeiten soll, sondern dass ihr mit Eurer zur Verfügung stehenden Arbeitskraft die Arbeit, die im System steckt auch schafft. 

Aber woran liegt diese immer wiederkehrende Fehleinschätzung?

Vielleicht an einem weiteren Aspekt, der sich auch hartnäckig in den Köpfen der Menschen hält. Dem Märchen vom Multitasking. Versuche mal, Deinen Namen 5x untereinander zu schreiben und und jeweils 5x nur den ersten, dann den zweiten Buchstaben und dann den dritten zu schreiben usw. Und dann schreibe mal 5x Deinen Namen untereinander, so wie Du es gewöhnlich machen würdest und vergleiche die Zeit, die Du bei beiden Varianten gebraucht hast. Durch das ständige Umschalten im Kopf brauchst Du Zeit. Mann und auch nicht Frau kann nicht zwei Dinge gleichzeitig tun – es wird im Kopf dann immer umgeschaltet – es muss sich auf die neue Situation wieder eingestellt werden und das kostet immer Zeit. Daher ist es eben sinnvoll sich solange auf eine Sache zu fokussieren, bis sie fertiggestellt ist. Das spart Zeit – eben die Umstellungszeit. (diesen Fokus, denn kennen wir natürlich auch aus Scrum)

Also – dann komme ich mal so langsam zum Ende…

Ich fasse mal zusammen: wenn wir die Arbeit im System begrenzen, werden wir schneller. 

Also müssen wir für jeden Arbeitsschritt, den wir uns für unseren Workflow ausgedacht haben einen Wert festlegen, der nicht überschritten werden darf.  – Also wir müssen sozusagen die Größe des Schreibtisches festlegen. Und daran müssen wir uns halten

Es hat sich bewährt einfach nach folgender Faustregel zu beginnen: 

WIP Limit ist entsprechend der Anzahl der Teammitglieder, die in dem Workflowschritt zusammenarbeiten und deren Auslastung bei 80% liegt…Dann schauen, wie es funktioniert und justieren den Wert, wenn wir feststellen, dass es nicht so gut läuft.

Damit halten wir zuviel Arbeit aus dem System heraus, so dass der Fluß ungestört fließen kann. 

Damit schaffen wir es verlässliche Aussagen zu machen, wann denn eine Arbeit (also eine Karte) fertig sein wird, denn wir können diese Zeit ja dann messen und – da der Fluß nicht ständig unterbrochen ist , wird diese Zeit auch einigermaßen realistisch eingehalten. Und eine verlässliche Aussage wie „Dein Ticket wird zu 80% in 5 Tagen gelöst sein“ wird deinen Kunden sicherlich zufrieden stellen und besser sein als „wir haben schon angefangen…“ mit der darauf folgenden Frage „und wann wird es fertig sein“  naja – wir haben noch so viele Dinge, dass ich das jetzt nicht genau sagen kann . Das hängt davon ab…Du weißt beziehungsweise kennst das flaue Gefühl in der Magengegend, wenn Du solche Unterhaltungen führen musst…

Ich wünsche Dir viel Erfolg beim Limitieren…Du wirst sehen, das macht dich frei… und Freiheit ist ja ein hohes Gut.

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 21: die Magie der WIP Limits
Markiert in:         

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.