Lean Thinking und Softwareentwicklung

Lean Thinking heißt Wert schaffen

Lean kommt aus der industriellen Produktion im Japan der sechziger Jahre und wurde über Toyota und das Toyota Production System TPS auch im Westen bekannt.

Lean bedeutet: „Werte ohne Verschwendung schaffen“.

Verschwendung? Alles, das keinen Wert schafft.

Verschwendung ist alles, was keinen Wert für Kunden oder für das Unternehmen schafft.

Das bestehende System wird also aus diesen beiden Perspektiven betrachtet: aus der Sicht des Kunden, dessen Wünsche es möglichst optimal zu erfüllen gilt, und aus der Sicht des Unternehmens selbst, das profitabel funktionieren und seine Wettbewerbsfähigkeit verbessern muss.

Gerne wird das Vermeiden von Verschwendung, von Überflüssigem in den Vordergrund gestellt. Das ist Teil des Ansatzes und mittendrin — doch es geht um eine andere Sicht: proaktives Verhalten und um Flow, um den reibungslos optimierten Fluss im Produktionsprozess.

Lean und das Toyota Production System

Taiichi Ohno und Shigeo Shingo werden als ‘Väter’ des Toyota Production System, TPS, bezeichnet, das zwischen den 1940er bis Mitte der 1970er vor allem in der Automobilproduktion Abläufe umkrempelte und erhebliche Effizienz- und Qualitätsvorteile brachte.

»Let the flow manage the processes, and not let management manage the flow«

Taiichi Ohno
Taiichi Ohno
Taiichi Ohno

»Lean is a way of thinking- not a list of things to do.«

Shigeo Shingo
Shigeo Shingo
Shigeo Shingo

Lean Production

  • Ein langfristiges Ziel definieren — was ist wichtig für das Unternehmen, was bedeutet ‘Wert’? Bei Toyota als Automobilunternehmen war das die effektive Herstellung von Autos.
  • Den Wertstrom abbilden — Die Ablauforganisation hat unbedingten Vorrang vor der Aufbauorganisation. Hierarchien oder Silos dürfen den unterbrechungsfreien Durchlauf nicht behindern. Es geht nicht mehr darum, alle Ressourcen optimal auszulasten, sondern um die Wertschöpfung, das Ergebnis, salopp: was hinten herauskommt. Bei Toyota also Autos, die sich gut verkaufen.
  • Ein Pull-System etablieren — In einer nach Lean-Prinzipien organisierten Produktion wird immer auf Anforderung der nächsten Bearbeitungsstation produziert, nicht auf Vorrat. Das bedeutet, dass die Produkte und Zwischenprodukte immer genau dann (just in time) geliefert, verarbeitet und fertiggestellt werden, wenn sie gebraucht werden. So werden Zwischenlager vermieden oder minimal klein gehalten und damit auch deren ökonomisch negative Folgen wie Kapitalbindung, Verwaltungsaufwand und das Risiko, nicht weiter benötigte Bauteile vorzuhalten. Das Pull-Prinzip erfordert ein proaktives Mitdenken der Mitarbeiter in der Produktion und direkte Koordination auf Arbeitsebene. Die aktive Teilnahme und Teilhabe macht Lean zu einem humaneren System als etwa konventionelle tayloristische Methoden, die detaillierte Vorgaben machen und Arbeitsschritte mit der Stechuhr optimieren.
  • Flow erzeugen — Flow, Durchfluss erzeugen bedeutet: in kurzen Zyklen, in kleinen und regelmäßigen Chargen, Wert zu produzieren.
  • Perfektionieren — Funktioniert der Flow, wird kontinuierlich optimiert und perfektioniert, um die Qualität zu steigern, Ausschuss zu vermeiden und so die Effektivität zu erhöhen.

Bekannte Begriffe aus dem TPS

Einige der TPS-Elemente und -Begriffe wurden über das TPS hinaus bekannt:

  • Muda — das Eliminieren von waste, Verschwendung, Überflüssigem
  • Jidōka — Autonomation oder autonome Automation: Maschinen produzieren nicht nur, sondern überwachen den Prozess auf Anomalien und stoppen bei minderer Qualität  (stop the line). Menschen erforschen und beseitigen Ursachen – und zwar sofort. Damit wird zwar der Produktionsfluss unterbrochen, aber Qualität hat damit absoluten Vorrang. Dies ist eine wichtige Voraussetzung für den kontinuierlichen Verbesserungsprozess.
  • Kaizen — ständige Prozessverbesserung mit Hilfe hochdisziplinierter Methoden der Problemlösung
  • Kanban — die Signalkarten für die just-in-time Vorratshaltung
Mura, Muda, Muri, Heijunka

Genchi Gembutsu: geh' hin und sieh' selbst

Eine der bekanntesten und wertvollsten Führungsprinzipien in Lean ist genchi gembutsu. Sie bedeutet so viel wie »geh’ hin und sieh’ selbst« — Entscheidungen sollen auf tiefer Kenntnis und aus aus erster Hand, vor Ort getroffen werden — nicht am grünen Tisch oder im stillen Kämmerlein.

Ohno bestand darauf, dass der Schlüssel des TPS eine Haltung sei, die Art wie ein Problem erfasst und dann gelöst wird. So nutzte es den erstaunten Abgesandten der US-Automobilindustrie auch recht wenig, das TPS vor Ort zu beobachten. Ohno lud förmlich zu Besuchen ein — er hatte keine Bedenken, die Amerikaner würden das Vorgehen einfach kopieren können — da es um eine Einstellung und Haltung geht und nicht um das Imitieren von Prozessen.

»Why not make the work easier and more interesting so that people do not have to sweat? The Toyota style is not to create results by working hard. It is a system that says there is no limit to people’s creativity. People don’t go to Toyota to ‘work’, they go there to ‘think’.«

Taiichi Ohno
Taiichi Ohno
Taiichi Ohno

Quellen

TOYOTA MOTOR CORPORATION. n.d. ‘Toyota Production System | Vision & Philosophy | Company’. Toyota Motor Corporation Official Global Website. Accessed 13 June 2019. https://global.toyota/en/company/vision-and-philosophy/production-system/index.html.

Ries, Eric. 2011. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. 1st ed. New York: Crown Business.

Takashi Tanaka, Sharon Tanner, and Craig Flynn, “The Basics of Oobeya,” Toyota Engineering Co. QV System, Inc. (2011), http://www.leanuk.org/downloads/LS_2011/mc_oobeya_basics.pdf

Lean (Software) Development

Lean Development ist die Anwendung der Prinzipien der Lean Production auf die (Software)-Entwicklung: wichtig ist, was als Resultat der Entwicklung das nutzenstiftende Produkt.

In der Entwicklung gelten bei gleichen Prinzipien andere ökonomische Parameter als in der industriellen Produktion:

  • Zykluszeiten von Wochen oder Monate statt Minuten
  • Kostenstrukturen, die es sinnvoll werden lassen, mehrere alternative Lösungen parallel zu entwickeln (concurrent engineering). Wenn eine Lösungsidee nicht funktioniert, kann man ohne Zeitverlust auf eine andere umschwenken, anstatt “zurück auf Los” zu gehen. die Kosten paralleler Entwicklungen können im Vergleich zu den Kosten eines Zeitverzugs (cost of delay) marginal sein
  • Das Erwerben von Wissen und die Reduktion von Unsicherheit hat bei der Softwareentwicklung als Wissensarbeit einen Wert an sich. Anders als bei der industriellen Produktion kann es sein, dass zu Beginn nur ein Zielkorridor bekannt ist (set based development) und sich mit mehr Informationen die Parameter und Randbedingungen erst im Lauf der Zeit verengen.

Mary und Tom Poppendieck haben mehrere Prinzipien speziell für die Software-Entwicklung definiert. Es gibt sie in mehreren Versionen, die aktuellste listet auf:

Optimize the Whole

  • Klarstellen des Zwecks: nicht Geschäfte machen, um Geld zu verdienen, sondern Geld verdienen um im Geschäft zu bleiben
  • Den gesamten Wertstrom im Blick haben – from concept to cash
  • Denke langfristig: rückwärts denken aus der Zukunft, vorwärts denken an zukünftige Generationen

Focus on Customer

  • Die richtigen Fragen stellen: das ermöglicht Innovationen
  • Das richtige Problem lösen: Fokus nicht auf das Produkt, sondern auf das Kundenproblem.
  • Eine großartige Erfahrung ermöglichen: Kundenzufriedenheit ist nicht genug. Kunden sollen das Produkt lieben.

Reduce Friction – Reibung reduzieren

  • Das richtige Produkt bauen
  • Das Produkt richtig bauen
  • In Wertströmen denken, Stapel und Warteschlangen vermeiden

Enhance Learning

  • Mit Unvorhersehbarkeit leben: Annahmen über eine unsichere Zukunft nicht als Plan deklarieren, sondern sich schnell der Entfaltung von Möglichkeiten anpassen
  • Wissenslücken schließen, verschiedene Optionen entwickeln, Teams häufig synchronisieren
  • Entscheidungen zum last responsible moment treffen, so dass Optionen möglichst lange bestehen bleiben

Increase Flow

  • Geschwindigkeit, Qualität und geringe Kosten sind vereinbar und ermöglichen sich gegenseitig
  • Flow-Effizienz statt Ressourcen-Effizienz
  • Den Workflow managen statt aufgabenorientierter Pläne

Build Quality In

  • Test als Spezifikation nutzen. Laufend testen, während der Entwicklung und auf allen Systemebenen.
    Früh und oft integrieren
  • Fehler nicht tolerieren. Fehler, die erst spät in der Entwicklung gefunden werden, zeigen, dass der Entwicklungsprozess selbst fehlerhaft ist.

Keep Getting Better

  • Verändere dich so schnell wie die Welt sich verändert
  • Widme dich auch den kleinen Fehlern. Dadurch entsteht verlässliche Leistungsfähigkeit
  • Verwende die Scientific Method: Führe Experimente durch, die auf Hypothesen basieren.
  • Erzeuge angemessene Dokumentation und implementiere die beste Alternative.
Mary Poppendieck
Mary Poppendieck
Tom Poppendieck
Tom Poppendieck

Diese Prinzipien des lean software development sind agilen Prinzipien sehr ähnlich. Manche stellen eine wertvolle Ergänzung dar, insbesondere der Blick auf das “Große Ganze”, über den Tellerrand eines einzelnen (Scrum-)Teams hinaus: einen Zweck definieren, in Wertströmen denken, globales statt lokales Optimum suchen. Damit lässt sich agiles Vorgehen skalieren und auf die gesamte Organisation ausweiten. Aus einzelnen agilen Teams wird Business Agility und eine agile Organisation.

7 Quellen der Verschwendung

Der Transfer von Produktion zu Softwareentwicklung wird schön in dieser Tabelle deutlich, die die 7 Quellen Verschwendung gegenüberstellt:

Manufacturing

Software Development

Inventory (Bestände): an verschiedenen Stellen der Wertschöpfungskette (Rohmaterialien, Work in Process, Fertigprodukte)

Partially Done Work: läuft Gefahr, obsolet zu werden und verzögert die Erkenntnis, ob das Problem gelöst werden kann oder nicht

Overproduction: wenn mehr produziert wird, als der Kunde aktuell abnehmen kann oder will

Extra Features: Features, die ohne erkennbaren Nutzen “für alle Fälle” entwickelt werden. Dies bedeutet nicht nur Aufwand in der Entwicklung, sondern auch bei der fortlaufenden Wartung. Das Softwaresystem wird unnötig kompliziert.

Overprocessing / Overengineering: die Prozesse verkomplizieren das Vorgehen und legen mehr fest als nötig wäre

Extra Processes: z.B. Papierkram, notwendige Unterschriften für Freigaben

Transportation: Rohmaterialien Werkstücke, Fertigprodukte, Werkzeuge…

Task Switching: z.B. dadurch, dass Menschen unterschiedlichen Projekten gleichzeitig zugewiesen sind

Waiting: der Mitarbeiter wartet auf das Produkt, oder das Produkt wartet auf Mitarbeiter (die gerade mit etwas anderem beschäftigt sind)

Waiting / Delays: z.B. schon vor dem Start eines Projekts durch die Zuweiseung von Budget und Mitarbeitern, ausführliche Spezifikationen;

Motion: Weiterreichen von Werkzeugen, Gang zur zentralen Werkzeugausgabe…

Motion: z.B. durch das Einholen von Informationen, das Arbeiten an unterschiedlichen Standorten

Defects: Ausschuss / Nacharbeit durch Fehler, besonders wenn sie erst am Schluss der Wertschöpfungskette gefunden werden.

Defects: je später der Fehler gefunden wird, desto mehr Nacharbeit ist damit verbunden

Quellen:

Poppendieck, M., & Poppendieck, T. (2010). Lean software development: An agile toolkit (Nachdr.). Addison-Wesley.
Poppendieck, M., & Poppendieck, T. D. (2014). The lean mindset: Ask the right questions. Addison-Wesley.

Lean Thinking und Scrum

Lean Thinking ist die Fusion dieser Prinzipien und ein Leadership-Prinzip, das den Mitarbeiter nicht mehr als Produktionsfaktor betrachtet, sondern ihn einbezieht. Es gibt eine Vielzahl von Varianten und industriespezifische Implementierungen.

Scrum macht sich viele der Lean-Prinzipien und ist direkt aus Lean oder TPS entwickelt. Scrum basiert nach Jeff Sutherland auf “The New New Product Development Game” von Hirotaka Takeuchi and Ikujiro Nonaka (Harvard Business Review, 1986). Die frühen Artikel zu Scrum lesen sich wie Exzerpte zu Lean Development.

Takeuchi und Nonaka haben übrigens für viele lean organisierten Firmen gearbeitet (z.B. Toyota, Honda), sprachen aber selbst nicht primär über Effizienz. Sie interessierten sich für Innovation und die Erzeugung von Wissen, weniger für die Optimierung von Produktionsprozesse.

Quellen

Takeuchi, H., & Nonaka, I. (1986). The New New Product Development Game. Harvard Business Review, 137ff.
Scroll to Top