Lean und Agile: Vorfahren und Verwandte

Das Agile Manifesto wurde 2001 geschrieben. Toyotas Produktionssystem begann sich in den 1940er Jahren zu entwickeln. Lean-Denken ist mehr als ein halbes Jahrhundert älter als Agile.

Das ist wichtig, weil Agile-Praktiken oft nur im Licht von Lean-Prinzipien Sinn ergeben. Warum bevorzugen wir „funktionierende Software vor umfassender Dokumentation"? Weil Dokumentation vor dem Programmieren Bestand ist – eine Form von Verschwendung. Warum wollen wir „auf Veränderung reagieren statt einem Plan folgen"? Weil langfristige Pläne Spekulation sind, und Spekulation produziert Verschwendung, wenn die Realität anders ist.

Viele Agile-Schwierigkeiten entstehen dadurch, dass Teams Praktiken übernehmen, ohne die zugrunde liegenden Prinzipien zu verstehen. Sie machen Daily Standups, weil Scrum es sagt, nicht weil sie verstehen, wie es Koordinationsverschwendung reduziert. Sie timeboxen Sprints, weil das das Framework ist, nicht weil sie verstehen, wie kleine Batches das Risiko reduzieren.

Wenn Sie Lean verstehen, werden Agile-Praktiken offensichtlich. Wenn nicht, erscheinen sie wie willkürliche Rituale.

Scrum übernahm mehrere Lean-Konzepte:

• Timeboxing als Batch-Size-Einschränkung
• Cross-funktionale Teams zur Reduzierung von Übergaben
• Retrospektiven für kontinuierliche Verbesserung
• Selbstorganisation als Respekt vor Menschen
• Funktionierende Software in jedem Sprint (JIT-Lieferung)

Extreme Programming (XP) ist noch expliziter Lean:

• Pair Programming reduziert Defekte (Qualität einbauen)
• Continuous Integration verhindert Bestand (kleine Batches)
• Test-driven Development fängt Bugs früh ab (Jidoka)
• Einfaches Design vermeidet Verschwendung (YAGNI)
• Nachhaltiges Tempo respektiert Menschen

Kanban ist die am direktesten von Lean abgeleitete Methode. David Anderson adaptierte explizit TPS-Konzepte: Pull-Systeme, WIP-Limits, Flow-Visualisierung, kontinuierliche Verbesserung. Wenn Scrum Leans Philosophie übernahm, übernahm Kanban seine Mechanismen.

Keine dieser Methoden erfordert, dass Sie Lean verstehen, um sie zu nutzen. Aber Lean zu verstehen hilft Ihnen:

• Zu wissen, wann man die Regeln brechen sollte
• Praktiken an Ihren Kontext anzupassen
• Zu diagnostizieren, warum Dinge nicht funktionieren
• Praktiken kohärent zu kombinieren

Während Lean das Fundament liefert, fügte Agile wichtige Elemente für Wissensarbeit hinzu:

Unsicherheit annehmen: Lean in der Fertigung optimierte bekannte Prozesse. Softwareentwicklung steht vor fundamentaler Unsicherheit – wir wissen oft nicht, was wir bauen oder wie wir es bauen sollen, bis wir es versuchen. Agile baut explizit Mechanismen für Entdeckung ein: Iterationen, User-Feedback, Pivots.

Timeboxes: TPS brauchte keine Sprints – die Produktion war kontinuierlich. Agile führte Timeboxes als Forcing-Funktion für Software-Teams ein, die an kontinuierlichen Flow nicht gewöhnt waren. Die Timebox schafft Rhythmus, begrenzt Scope Creep und erzwingt regelmäßige Lieferung.

Zeremonien: Retrospektiven, Standups, Reviews – das sind Mechanismen für die Feedback-Schleifen, die Lean erfordert, zugeschnitten auf Wissensarbeitsteams. Sie sind nicht einzigartig für Agile (Toyota hatte ähnliche Praktiken), aber Agile kodifizierte sie für Software.

Das menschliche Element: Während Leans Säule „Respekt vor Menschen" tiefgründig ist, machte Agile es für Wissensarbeit expliziter. Das „Individuen und Interaktionen über Prozesse und Werkzeuge" des Manifests und XPs „nachhaltiges Tempo" betonen, dass Wissensarbeit intrinsische Motivation erfordert, nicht nur Prozesseffizienz.

Weder Lean noch Agile ist allein vollständig. Lean liefert Prinzipien und Theorie. Agile liefert spezifische Praktiken für Software. Die besten Teams schöpfen aus beiden.