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 Software- und Produktentwicklung 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.
Diese Prinzipien des lean software development sind agilen Prinzipien sehr ähnlich. Manche sind eine wertvolle Ergänzung wie der Blick auf das Ganze und ü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 in den 7 Quellen der Verschwendung gegenüberstellt sind:
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 Zuweisung 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:
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