Lean 

Was ist dieses Lean? Wo kommt es her? Was haben wir davon?

Die Grundidee von Lean ist maximalen Wert für Kunden zu schöpfen und dabei Waste zu vermeiden. Genau wie “agil” ist es eine Art zu Denken. Mit einem leanen Mindset fragt man sich:

  • Schafft das hier gerade Wert?
  • Interessiert das irgendeinen Kunden / Benutzer?
  • Kann ich das auch einfach weglassen (oder weniger machen)?

Wer hat's erfunden?

Fast alles was wir als Lean kennen, kommt von Toyota (ja, die japanische Autofirma). In den 40er-60er Jahren hat dort Taiichi Ohno das Toyota Production System (TPS) aka Lean Production aka Lean Manufacturing erfunden. Kanban, Scrum, Just-In-Time (JIT), Stop-the-Line (Jidoka) – stammen alle aus dieser Zeit. [Mehr zur Geschichte der Familie Toyoda [sic!] erfährst Du bei der Santa Maria Schulung.]

Ohno selbst hat dem ganzen nie einen Namen gegeben. Mit voller Absicht, denn wenn man dem System einen Namen gibt, dann “erwarten Manager, dass man es in einer Packung kaufen kann”.

John Krafcik hat dann 1988 den Namen “Lean Production System” erfunden und Womack, Jones und Roos haben ihn in ihrem Buch “The Machine that changed the World” (“Die zweite Revolution in der Autoindustrie”) von 1990 breit bekannt gemacht. Das Buch ist heute noch interessant zu lesen, auch als zeitgeschichtliches Dokument (in allen Tabellen ist noch die DDR).

Ohno hatte Recht mit seiner Zurückhaltung. Nachdem das Kind einen griffigen Namen hatte, wurden vor allem Praktiken wie Just-in-Time (Produktion ohne große Lagerbestände, durch Anlieferung zum richtigen Zeitpunkt) übernommen, ohne das zugrunde-liegende Mindset. Bei Toyota wurden Zulieferer als Partner gesehen, mit denen zusammen auf JIT hingearbeitet wurde. Ohne diese Einstellung klappt JIT nicht so gut wie bei Toyota.

Wenn es nicht um die konkreten Praktiken geht, worum geht es denn dann?

Die 2 Säulen von Lean

Noch mal kurz die Ziele: Nachhaltig höchstes Value liefern, mit den geringsten Kosten, der kürzesten Durchlaufzeit und dabei noch hohe Team-Moral. Ganz schön ehrgeizig.

Lean will das erreichen durch:

  • Kontinuierliche Verbesserung (Kaizen) und
  • Respekt vor Menschen

“Kontinuierliche Verbesserung” beinhaltet:

  • Gemba Walk = Hingehen und angucken wo etwas passiert, nicht im Elfenbeinturm hocken
  • Poka Yoke = Gestalte etwas so, dass Fehler gar nicht erst passieren
  • Sich selbst herausfordern

“Respekt vor Menschen” beinhaltet:

  • Gegenseitiger Respekt und Vertrauen
  • Teamwork
  • Ehrliches Feedback
  • Alle Zulieferer, Kunden etc. als gleichberechtigte Partner wahrnehmen und behandeln

Muda, Mura und Muri

Teil der kontinuierlichen Verbesserung ist die Vermeidung von Muda, Mura und Muri. Bitte, was?

Es gibt 3 Dinge, die Abläufe ins stottern bringen:

  • Muda – Überflüssiges – Waste
    Das sind Dinge, die nicht wertschöpfend sind und man sich komplett sparen sollte. Beispiele:

    • Reisekostenabrechnung. Trägt nix zum Produkt bei. Kein Kunde zahlt dafür. Also grade eben das nötigste machen, damit das Finanzamt nicht meckert
    • Die 100 Seiten Powerpoint-Präse, von denen nur 5 Slides nötig waren
    • Meetings in denen nichts entschieden wird, weil die entscheidende Leute fehlen (was auch von Anfang an klar ist)
    • Politische Spielchen
  • Muri – Uneinheitlichkeit – Imbalance
    Am schönsten ist, wenn die anfallende Arbeit immer ungefähr gleich viel ist. Dann braucht man keine krassen Überlastungsspitzen abzufangen oder sich auf dem Bürostuhl zu drehen, wenn einfach nix zu tun ist.
  • Mura – Überlastung – Overburden
    Wenn insgesamt mehr Arbeit im System ist, als abgearbeitet werden kann, wird alles immer langsamer. Das ist wie auf der Autobahn: Je näher die Auslastung an 100% ist, desto Stau. Auch Rettungsgasse klappt dann nur noch mit Glück.

Wartezeiten steigen, alle sind gestresst, man kann kaum noch sinnvoll agieren und ein Notfall bringt alles zum Zusammenbruch. Es sind zwar alle wahnsinnig beschäftigt, aber hinten kommt nichts bei rum. Nichts wird fertig.

Mit 80% Auslastung fährt man ganz gut, man kann agieren statt nur reagieren und auch Notfälle kann man verarzten ohne das alles zum Stillstand kommt.

Muri und Mura verursachen Muda.

7 Wastes (of Software Development)

Wie gesagt, Lean kommt aus dem Bereich der industriellen Fertigung. Wenn man, wie wir, in der IT arbeitet, muss man ein bisschen Transferleistung erbringen. Oder die von anderen lesen. Zum Beispiel die von Mary und Tom Poppendieck in ihrem Buch “Lean Software Development”. Darin haben sie unter anderem die “7 Wastes” aus der Lean-Literatur übertragen auf Software Entwicklung.

 

Original “7 Wastes” “7 Wastes in Software Development”
  1. Lagerbestand (Inventory)
  2. Überproduktion (Overproduction)
  3. Extra Bearbeitungsschritte (Extra Processing)
  4. Transport (Transportation)
  5. Wartezeiten (Waiting)
  6. Bewegung (Motion)
  7. Defekte (Defects)
  1. Unfertige Arbeit (Partially Done Work)
  2. Extra Features
  3. Relearning
  4. Handoffs
  5. Wartezeiten (Delays)
  6. Task Switching
  7. Bugs (Defects)

 

Value Stream

Damit man weiss, was nun überflüssig und was Wert schöpfend ist, muss man sich das eigene Geschäft angucken. Welcher Wertstrom wird da erzeugt? Bei einer Spieleschmiede könnten das die Abläufe von “Idee” bis “Spiel ist kaufbar” sein. Bei einer Ärztin alles zwischen “Patient macht Termin” und “Patient verabschiedet sich (ggf. mit Rezept)”.

Wenn man den eigenen Value Stream mal gemappt hat, kann man ihn anschließend optimieren:

Zu dem Thema gibt’s wieder eigene Bücher.

TODO: HABEN WIR EINE EMPFEHLUNG?

Theory of Constraints

Wenn man am Wertstrom rum-optimiert, sollte man immer an der engsten Stelle, dem sogenannten Bottleneck ansetzen. Das was hinten rausfällt wird nämlich nicht mehr, wenn man an Stellen optimiert, die gar nicht so sehr das Problem sind.

Beispiel: Wir setzen Features nicht schnell genug um. Lösung: Mehr Entwickler!

Problem: Es hakt gar nicht an der eigentlichen Entwicklung, sondern am Live stellen, weil es nicht genügend Admins gibt (und DevOps noch in weiter Ferne).

Mehr Entwickler nützen also genau gar nix. Das Problem wird schlimmer, mit immer größeren Stapeln Features, die auf Live-Stellung warten, in denen Fehler dann später bemerkt werden, … Ein Teufelskreis. Der bessere Ansatz: Entwickler die aufhören Features zu entwickeln und stattdessen Schritte beim Live-Gang automatisieren.

Diese Theory of Constraints hat Eli Goldratt sehr anschaulich im Sach-Roman “The Goal” ausgeführt.

Bonus: Japanisch für Anfänger