Aus der Lean Production ist neben all den Erfahrungen auch einiges an Theorie entstanden. Das wohl wichtigste ist die theoretische Begründung dafür. warum große Lose nur vordergründig zur Effizienzsteigerung beitragen.

Die Argumentation (ich kann sie nur nicht-mathematisch vortragen) geht ungefähr so: sobald in einer Kette von Fertigungsschritten einer der Schritte eine Verzögerung aufweist, kann der nächste Schritt nur verzögert beginnen. Da die Abarbeitung in den meisten Fällen nicht einfach schneller gemacht werden kann, verzögert sich nicht nur die Auslieferung, sondern es kommt in allen folgenden Schritten zu Wartezeiten alias geringerer Auslastung. Die Auswirkungen sind umso gravierender, je größer die Losgrößen und die Fertigungstiefe werden (sagt die Mathematik - sag ich jetzt so).

Die Gegenmaßnahme besteht darin, kleine Mengen weiterzugeben und nicht bei jeder Fertigungsstufe 100 Prozent Auslastung einzuplanen.

Warum das für die Software relevant ist? Wir bauen zur Verdeutlichung einen Mini-Prozess: Codieren und anschließendes Testen. Jetzt können wir sofort einige Analogieschlüsse ableiten:

• Die Übergabe des Codes sollte in kleinen Einheiten erfolgen - sonst steigen die Wartezeiten bei den Testern und die gesamte Durchlaufzeit an.
• Tester sollten nah bei Codierern sitzen - direkte Kommunikation erleichtert und unterstützt das Verstehen des Codes, das Übernehmen eines einzelnen Tasks, also die Rüstzeiten
• Am besten ist eine ganzheitliche Bearbeitung wie in einer Fertigungszelle - wenn Unit-Tests direkt vom Entwickler erstellt und durchgeführt werden, sinkt die Fertigungstiefe.

Das ist ziemlich nützlich an Lean Thinking: das Denken beginnt beim Prozess - bei Agile beginnt es beim Team: es eröffnet eine Prozess-Sicht auf Agile Entwicklung und kommt oft zu gleichen oder ziemlich ähnlichen Ergebnissen.