Nun laufe ich ja immer durch die Gegend und predige in Entwicklungsprozessen (und im Rest des Lebens) die Losgröße so klein wie möglich zu halten. Das ist nicht immer einfach (also das Halten, nicht das Predigen), denn wir sind seltsamerweise alle mit der Meinung sozialisiert, dass große Losgrößen etwas Gutes und Effizientes sind. Auch wenn der Verstand inzwischen weiß, dass dem nicht so ist, die alten Reflexe schlagen manchmal durch. Und hier habe ich ein Beispiel wie damit ein ganzes Projekt gescheitert ist.
Ich versuche ja alles, was sich in der Welt der Entwicklungsprozesse bewährt auch im Alltag umzusetzen. Die Familie organisiert sich über ein Kanban-Board, Hausaufgaben werden in Wochensprints mit Scrum gemacht und ich, der Papa, setzt wo er kann auf Single-Piece-Flow. Ja, das kostet Überwindung, aber ich kuvertiere Rechnungen und Korrespondenz einzeln, baue Möbel einzeln zusammen, und so weiter. Obwohl, neulich habe ich kleine belegte Brote für den Aperitiv geschmiert, da habe ich alles zuerst geschnitten, dann geschmiert, dann belegt. Mon dieu, maximale Losgröße. Naja, das ging aber zum Glück gut aus.
Warum ist denn eine minimale Losgröße anzustreben? Zum einen bieten kleine Losgrößen frühes Feedback. Wenn sich irgendwo ein Denk- oder Materialfehler eingeschlichen hat, fällt das auf, bevor man unmenegen von Zeit und Material in eine fehlerhafte Charge investiert hat. Zum anderen reduzieren kleine Lose die Bestandskosten (bei Fertigung und Co.) und die Liegezeiten bei Service-Prozessen wie z.B. in der Produktentwicklung. Dass Liegezeiten Geld kosten (Cost of Delay, COD), habe ich in meinem Beitrag über den Mythos Vollauslastung ausgeführt. Natürlich ist Single Piece Flow nicht immer das Optimum, je nach COD / Bestandskosten und Transaktionskosten (z.B. Rüstkosten, Testaufwand), muss eine optimale Losgröße gefunden werden. In der Fertigung klappt das ganz gut (die Lean-Bewegung hat da viel bewirkt), aber in Entwicklungsprozessen und beim Brote schmieren, tendiert der Mensch zu maximalen Losgrößen. Ganz schlimm sind zum Beispiel Stage-Gated Prozesse, in denen bei Vorliegen bestimmter Bestimmungen von einer Projektphase in die nächste weitergeschaltet wird. Und da warten dann zum Beispiel 199 arme CAD-Zeichnungen auf ein Review, weil die 200. Zeichnung auch fertig sein muss, bevor’s ins Review geht. Teure Liegezeiten und sehr spätes Feedback. Ein Denkfehler in der Konstruktion offenbahrt sich maximal spät, wenn alle 200 Zeichnungen fertig sind. Agile Methoden haben gezeigt, dass es auch anders geht, sie setzen auf kleine Lose für schnelles Feedback und kleine Liegekosten.
Nun jedoch zu meinem Fallbeispiel, in dem bei mir die weitverbreitete Stage-Gated-Sozialisierung mein Projekt scheitern ließ. Ich sitze morgens im Mercure Hotel im Hafen von La Rochelle (also da wache ich nicht jeden morgen auf, das war im Urlaub). Am Buffet gibt es tatsächlich Pancakes, wie ich sie aus dem Mercure in Braunschweig kenne (ich dachte aber nur, dass alles gleich ist).
Also habe ich mir drei dieser Prachtexemplare auf den Teller gehievt, hinreichend viel Ahorn-Sirup drüber und zurück an den Platz. Zu was die Crêpes-Platte mit den vielen kleinen Kunstoff-Schabern am Büffet war, konnte ich zu dem Zeitpunkt gar nicht einordnen. Ich, zurück am Platz, schnippel mir ein Stück Pancake herunter, entspannter Blick auf den Hafen, und…. igitt, die Dinger sind eiskalt. Panik kommt auf, dann Hunger, dann Nachdenken. Am Ende des Nachdenkens (so nach zwei kalten Pancakes) eine Art Erkenntniss. Die Crêpes-Platte und diese Schaberchen, sind wohl dazu da, die kalten Pancakes aufzubacken. Also doch nicht so wie in Braunschweig. Bis ich aber alle Puzzelteile zusammen hatte, waren die Pancakes fast weg, ich fast satt. Mir nochmal eine warme Portion zu bauen hätte sich nicht gelohnt. Satt durch kalte Pancakes. Projekt gescheitert.
Was war geschehen? Ich habe unbewusst die Transaktionskosten (zum Büffet gehen und zurück) viel zu hoch eingeschätzt und habe auf die maximale Losgröße (drei Pancakes) gesetzt. Damit einher ging der Denkfehler, dass alles wie in BS ist. Das Feedback kam nach dem ersten Bissen, aber die Einordnung dieses Feedbacks hat noch einige Bissen mehr benötigt. Es war also nicht nur die Losgröße, sondern eine Kombination:
- Zu große Losgröße
- Mentale Modelle (hier muss ich wieder auf das Thema Team Resource Management verweisen)
- Trägheit
Also alles wie in echten Entwicklungsprojekten. Ich bin überzeugt, dass wenn ich beim Pancake auf Single-Cake-Flow gesetzt hätte, das mentale Modell früher kollabiert wäre, und ich zumindest noch ein bis zwei warme Pancakes ergattert hätte. Das wird mir eine Lehre sein.
Und ich werde weiterhin die Augen offen halten um zu berichten, wo uns der Alltag etwas über unsere Beratungsthemen lehren kann.
Bis dann!