digitalien.org — Stefan Knecht

Lean in der Softwareentwicklung

Lean Development ist die Anwendung der Prinzipien von Lean Production und Lean Thinking ➚ auf die (Software)-Entwicklung: es zählt das nutzbare Resultat der Entwicklung, das nutzenstiftende Produkt — alles andere gilt es ständig zu überprüfen.

In der Softwareentwicklung gelten 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 ohne Zeitverlust auf eine andere gewechselt werden, anstatt “zurück auf Los” zu gehen. Die Kosten paralleler Entwicklungen können im Vergleich zu den Kosten eines Zeitverzugs (cost of delay, CoD) 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 bieten sieben Prinzipien aus lean für die Software-Entwicklung an. Es gibt sie in mehreren Versionen, die aktuellste ➚ listet auf:

Das Ganze optimieren, Optimize the Whole

  • 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 Nutzungsgenerationen

Auf den Kunden konzentrieren, 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.

Reibung reduzieren, Reduce Friction

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

Lernen verbessern, 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 bleiben Optionen möglichst lange offen

Durchsatz erhöhen, 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

Qualität einbauen, 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.

Ständig besser werden, 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:
    mache hypothesengetriebene Experimente
  • Erzeuge angemessene Dokumentation und implementiere die beste Alternative.
Mary Poppendieck
Tom Poppendieck

Lean Software Entwicklung in einem Bild

lean DEV — Prinzipien aus lean in der Softwareentwicklung

Prinzipien aus lean sind den agilen Prinzipien ähnlich

Diese Prinzipien des lean software development sind agilen Prinzipien sehr ähnlich.

Manche sind eine wertvolle Ergänzung wie der Blick auf das ‘Große Ganze’, über den Tellerrand eines einzelnen (Scrum-)Teams hinaus: einen Zweck definieren, in Wertströmen denken, globale statt lokale Optima suchen.

Mit den Prinzipien aus lean wird agiles Vorgehen skalierbar und lässt sich auf die gesamte Organisation ausweiten. Aus einzelnen agilen Teams wird im Konzert die Business Agility eines Unternehmens.

7 Quellen der Verschwendung​: Produktion und Softwareentwicklung

Der Transfer von Produktion zu Softwareentwicklung wird schön in dieser Tabelle deutlich.

Die bekannten 7 Quellen der Verschwendung der industriellen Produktion aus dem Toyota Production System sind der Entwicklung von Software gegenüberstellt:

Industrielle ProduktionEntwicklung von Software
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 willExtra 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äreExtra 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

Lean Thinking und Scrum​

Lean Thinking ist die Fusion dieser Prinzipien und ein Führungsprinzip, das den Mitarbeiter nicht mehr als Produktionsfaktor betrachtet, sondern ihn einbezieht.

Scrum übernahm viele der Lean-Prinzipien. Jeff Sutherland sagt, Scrum baue auf einem Beitrag “The New New Product Development Game” von Hirotaka Takeuchi and Ikujiro Nonaka auf. So lesen sich die frühen Artikel zu Scrum wie eine Zusammenfassung aus Lean Development.

Takeuchi und Nonaka haben übrigens für viele lean organisierten Firmen wie Honda oder Toyota gearbeitet, waren aber keineswegs Jünger der Effizienz. Beide interessierten sich für Innovation und die Erzeugung von Wissen, weniger für die Optimierung von Produktionsprozesse.

Mehr dazu: ➚ Was lean thinking ausmacht