Ist Agile Lean? Oder sind Agile und Lean völlig unterschiedliche Philosophien?

Kann ich sagen, dass Agilität „nicht“ Lean ist und sowohl Agilität als auch Lean völlig unterschiedliche Konzepte oder Philosophien sind?

Wenn ich Lean-Prinzipien nehme:

  1. "Selbstorganisation"
  2. "Kaizen oder kontinuierliche Verbesserung"
  3. "Qualitätssicherung"
  4. "Pokayoke oder ausfallsicher"
  5. „Mudha oder Abfallbeseitigung“

Ich sehe, dass Agile definitiv die ersten zwei und ein bisschen von 3 mit Rückkopplungsschleife erfüllt, aber nicht den Rest. Macht das Lean-Methoden wie Kanban überlegener? Keine Absicht, bestimmte Prinzipien zu untergraben, sondern eine logische Klarstellung, um ein klares Verständnis zu haben.

Antworten (6)

Agile und Lean haben unterschiedliche Wurzeln, aber bis zu einem gewissen Punkt überschneiden sie sich. Ersteres basiert auf dem agilen Manifest , während letzteres seine Wurzeln im Toyota-Produktionssystem hat, aber in vielen Bereichen sind beide Bewegungen aufeinander abgestimmt und werden oft als ähnliche Konzepte behandelt.

In dieser Frage und speziell in dieser Antwort finden Sie weitere Erläuterungen zu diesem Thema .

Wenn Sie mit orthodoxen Menschen sprechen, könnten sie darauf bestehen, dass Agilität und Lean völlig unterschiedliche Konzepte sind, aber da ich weit von einer solchen Einstellung entfernt bin, würde ich sagen, dass Agilität im Allgemeinen ziemlich genau Lean ist und umgekehrt.

Ein paar Anmerkungen: Ich bin nicht damit einverstanden, Lean nur auf Lean Software Development (was nur eine der Lean-Methoden für die Softwareentwicklung ist) oder Agile auf bestimmte Techniken wie TDD oder Methoden wie Scrum zu reduzieren. Sowohl Lean als auch Agile sind allgemeine Konzepte und Kanban, Scrum, Lean Software Development und so weiter sind nur spezifische Implementierungen dieser Konzepte.

Man kann auch nicht sagen, dass diese oder jene Methode anderen überlegen ist. Sie werden je nach Situation unterschiedliche Methoden anwenden wollen. Manchmal ist Scrum (gekennzeichnet als „Agile") besser und manchmal bevorzugen Sie Kanban (gekennzeichnet als „Lean"). Mein Rat hier: Hören Sie auf, über Labels nachzudenken, und überlegen Sie, was in jeder spezifischen Situation die sinnvollste Methode ist Sie erhalten keine Punkte dafür, agiler oder schlanker zu sein, sondern dafür, Ihre Projekte abzuschließen.

Selbst wenn Sie die Annahme bestimmter Methoden als Referenz dafür betrachten würden, ob Sie schlank oder agil sind, was falsch ist, würden Sie immer noch viele Überschneidungen feststellen. Und natürlich können Sie agil/schlank sein, auch wenn Sie keine benannte Methode verwenden. Es geht darum, Prinzipien zu folgen und nicht dem Buch zu folgen.

Wenn Sie das Thema aus dieser Perspektive betrachten, liegen Lean und Agile ziemlich nah beieinander und Sie können definitiv nicht sagen, dass sie "völlig verschieden" sind.

Ich denke, es ist richtiger zu sagen, dass sowohl das Toyota-Produktionssystem als auch Lean Software Development ihre Wurzeln im Lean Thinking haben. Moderne schlanke Softwareentwicklung ähnelt eher einer Produktentwicklung als einer Produktionslinie, und viele der Praktiken, die wir anwenden, sind nicht mehr von TPS abgeleitet.
"Sie werden je nach Situation unterschiedliche Methoden anwenden wollen." +1 nur dafür. Ist das nicht der ganze Sinn von Kaizen, kontinuierlicher Verbesserung, Postmortems und Reflexionen und so weiter – Identifizierung dessen, was funktioniert, was nicht, und Änderungen, damit der Prozess besser funktioniert?

Die meisten agilen Methoden erfordern selbstorganisierende Teams und einen Fokus auf die kontinuierliche Verbesserung des Prozesses und des Produkts. Ich würde aber auch argumentieren, dass Agilität Abfallvermeidung und Poka-Yoke sowie Qualitätssicherung in gewissem Umfang beinhaltet, abhängig von den spezifischen Methoden. Beispiele hierfür sind You Ain’t Gonna Need It/YAGNI und Test Driven Development.

Test Driven Development ergänzt die Qualitätssicherungspraktiken, indem sichergestellt wird, dass für alle Funktionen Testcode und Testverfahren entwickelt wurden, und indem Sie Tests entwickeln, die fehlschlagen, und dann Code schreiben, um die Tests zu bestehen, arbeiten Sie daran, Ihr System ausfallsicher zu machen. Zusammen reduzieren YAGNI und TDD Abfall, indem sie durchsetzen, dass nur der wesentliche Code produziert wird. YAGNI kann auch zur Dokumentation erweitert werden.

Sie können schlank sein, ohne agil zu sein, aber es ist sehr schwierig, wenn nicht unmöglich, agil zu sein, ohne schlank zu sein.

Ich denke, der Lean Software Development-Artikel auf Wikipedia ist insgesamt ziemlich informativ.

Lean war zuerst da, bevor die Agile-Bewegung begann. Toyota arbeitet seit dem Ende des Zweiten Weltkriegs an seinem TPS (Toyota Production System). Konzeptionell ist es noch in Arbeit und wird es immer sein. Die „Agile“-Bewegung im Software Engineering ist viel jünger.

So wie ich es sehe, haben beide viele ähnliche Konzepte. Eines der prominentesten Beispiele wäre die Denkschule von Mary und Tom Poppendieck (mehr Details hier und hier ). Es gibt jedoch eine Reihe unterschiedlicher Ansätze, die unter den Dachbegriff agiler Methoden passen, z. B. XP, Scrum, FDD, Crystal und andere. Aus dieser Perspektive könnte man sagen, dass Lean nur eine davon ist.

Andererseits gibt es Praktiken, die Teil des Lean-Denkens sind, aber im agilen Mainstream noch nicht so weit verbreitet sind, zB A3-Denken . Dies beginnt sich jedoch auch zu ändern, und ich vermute, der Grund dafür ist, dass immer mehr Menschen nach weiteren Lean-Techniken suchen, die für das Software-Engineering genutzt werden könnten.

Speziell zu den fünf Punkten, die Sie auflisten, wäre meine Ansicht wie folgt:

  1. Erfüllt von agiler Softwareentwicklung (Sie haben sich das bereits selbst beantwortet)
  2. Erfüllt von agiler Softwareentwicklung (Sie haben sich das bereits selbst beantwortet)
  3. Erfüllt durch agile Softwareentwicklung, zB TDD, aber andere mehr, zB häufige Iterationen und kleine Releases kombiniert mit Feedback
  4. Erfüllt von agiler Softwareentwicklung. Ausfallsicherheit kann durch Simple Design, TDD und andere erreicht werden
  5. Erfüllt von agiler Softwareentwicklung. Abfallbeseitigung kann durch Techniken wie gnadenloses Refactoring, einfaches Design, „Das Einfachste, das möglicherweise funktionieren könnte“ und YAGNI („Du wirst es nicht brauchen“) erreicht werden.
Auch der agile Iterationsprozess, wie z. B. ein lieferbares Produkt am Ende des Sprints, zwingt Sie dazu, Verschwendung mit der „Just-in-Time“-Denkweise zu eliminieren.

Lean, Kanban, Agile sind nur Werkzeuge, worauf es ankommt, sind Prinzipien. Der Typ, der Toyota unterrichtete, war eigentlich ein … Amerikaner, der in seinem eigenen Land unbekannt war, bis der ehemalige Ford-CEO Edwards Deming wiederentdeckte. Er wird im Sutherland-Seminar und in diesem Forbes-Video http://www.youtube.com/watch?v=6gfcvIUmdZU erwähnt

Sie können keines dieser Tools wirklich verwenden, ohne die Prinzipien zu verstehen. Tatsächlich sind diese Tools nicht so wichtig, nachdem Sie die Wurzeln der Dinge verstanden haben, sollten Sie in der Lage sein, Ihre eigenen zu erstellen, die an Ihre Organisation angepasst sind.

Siehe http://www.youtube.com/watch?v=GXVgsPxQR54&feature=player_embedded http://www.youtube.com/watch?v=GHvnIm9UEoQ&feature=player_embedded

The Poppendieck definierte Lean Software Development in ihrem wegweisenden Werk Lean Software Development: An Agile Toolkit

Die Forschung hat eine Reihe von Meinungen zu Lean und Agilität. In einer Umfrage zu agilen Methoden wurde Lean als eine Art agiler Methodik angesehen. (siehe „Empirische Studien zur agilen Softwareentwicklung: Eine systematische Übersicht“)

Lean hat sich in weiteren Untersuchungen gezeigt, dass es sich basierend auf zwei Faktoren von Agile unterscheidet. (siehe das Kapitel „Ist Lean Agile und Agile Lean?“ aus dem Buch Modern Software Engineering Concepts and Practices: Advanced Approaches ) Lean unterscheidet sich von agiler Entwicklung, weil es sich auf eine Sache konzentriert, was Agile nicht tut:

  • E2E: Lean hat das Prinzip der End-to-End-Verbesserung

Das E2E-Konzept ist wichtig, weil es den gesamten Prozess optimiert, anstatt nur Teile zu suboptimieren.

Ich habe dieses Jahr sowohl an Scrum- als auch an Agile-Zertifizierungsschulungen teilgenommen, in denen Lean als Vorläufer von Agile vorgestellt wurde, ein Teil des Bodens, aus dem Agile hervorgegangen ist.

Also keine völlig getrennten Philosophien.