Methoden der Softwareentwicklung: Lean vs. Agile Principles

„Lean“ und „Agile“ sind Begriffe, die in letzter Zeit oft im Zusammenhang mit Softwareentwicklungsmethoden, Projektmanagement oder Organisationsstilen verwendet werden.

Aber haben Sie sich schon einmal gefragt:

Was ist Lean? Was ist Agile? Gibt es da einen Unterschied?

Merriam-Webster Dictionary definiert Agile als „mit schnellem, einfallsreichem und anpassungsfähigem Charakter, oder gekennzeichnet durch die Bereitschaft, sich mit schneller, leichter Anmut zu bewegen.“

Lean wird einfach als „dünn und gesund, oder wenig oder kein Fett enthaltend“ definiert.

Ausgehend von diesen Definitionen können wir davon ausgehen, dass jemand, der schlank ist, und jemand, der agil ist, viele gemeinsame Eigenschaften haben könnten. Das gilt auch für die Softwareentwicklung.

Was ist agil? Was ist Lean?

Agile ist in der Welt der Technologie inzwischen weithin als eine Reihe von Werten und Prinzipien bekannt, die die Entwicklung von Software leiten. Das „Agile Manifest“ enthält eine Reihe von vier Werten und 12 Prinzipien. Auf den Punkt gebracht, ist Agile genau das, was man sich darunter vorstellt. Es ist agil. Der Begriff „Lean“ wurde ursprünglich geprägt, um ein Organisationsmodell für die Fertigung zu beschreiben, das auf dem Toyota-Produktionssystem basiert, wird aber gemeinhin als ein Unterrahmen innerhalb der agilen Softwareentwicklung betrachtet.

Heute herrscht große Verwirrung darüber, was Lean und was Agile ist, ob es sich um ein und dasselbe handelt und welche Methode verwendet werden sollte.

Die Geburt der neuen Softwareentwicklungsmethoden

Beide, Lean und Agile, wurden als Reaktion auf die Unzulänglichkeiten bestehender planorientierter Methoden wie Waterfall entwickelt. Die seit den 1970er Jahren angewandte Methode wurde in den 90er Jahren von Entwicklern und Softwareentwicklungsmanagern zunehmend als ineffizient empfunden. Angesichts dynamischerer Märkte und technisch versierter Verbraucher war Waterfall nicht mehr in der Lage, schnell genug auf Marktanforderungen und sich ändernde Technologien zu reagieren oder kontinuierlich fehlerfreie Software zu liefern.

Auf der Suche nach einem besseren Modell versuchten die Erfinder von Lean und Agile, Methoden mit einem stärker kundenorientierten Ansatz zu entwickeln. Die neuen Methoden betrachteten die Anpassungsfähigkeit als Wettbewerbsvorteil, bevorzugten frühzeitige und kontinuierliche Tests und brachten ein menschliches Element in das Projektmanagement und die Ausführung ein.

Schlanke vs. agile Prinzipien

Schlanke Softwareentwicklung (LSD) wurde erstmals von Dr. Robert Charette vorgeschlagen, um veränderungsfähige Organisationen aufzubauen, die zunehmend von Software abhängig sind.

Danach folgte „The Agile Manifesto“, das die 12 Prinzipien der agilen Softwareentwicklung festschrieb.

Das andere maßgebliche Werk über Softwareentwicklungsmethoden wird Mary und Tom Poppendieck zugeschrieben, die Lean Software Development veröffentlichten: An Agile Toolkit.

Hier ist eine Gegenüberstellung der Werte und Prinzipien beider Werke:

Vergleicht man die 12 Prinzipien von Dr. Charette’s LSD und die 12 Prinzipien von Agile, kann man sehen, dass sie auffallend ähnlich sind. Die von den Poppendiecks vorgeschlagenen sieben Lean-Prinzipien sind weniger zielgerichtet, überschneiden sich aber dennoch mit „The Agile Manifesto“ und Charettes Lean Software Development.

Hier sind weitere Elemente, die sie alle gemeinsam haben:

• Der Wert einer schnellen Reaktion auf Kundenbedürfnisse
• Frühes Testen
• Ein iterativer Entwicklungsansatz
• MVP (Minimum Viable Product)-Stil der Entwicklung gegenüber feature-lastig
• Zusammenarbeit sowohl innerhalb des Unternehmens als auch mit externen Stakeholdern

Zeitleiste

Wir haben die einschneidenden Ereignisse und Veröffentlichungen untersucht, aus denen diese Terminologien entstanden sind, um zu sehen, wie sie populär wurden. Werfen Sie einen Blick auf unsere Zeitleiste, die die Entwicklung aufzeigt, und fügen Sie sie Ihrer Leseliste hinzu, wenn Sie dazu geneigt sind!

Ursprünge von Lean und Agile

Wie Sie der Zeitleiste entnehmen können, wurde der Begriff Lean erstmals 1990 von Womack et. al. verwendet, um das Toyota-Produktionssystem in ihrem Buch The Machine That Changed The World zu beschreiben. Später adaptierte Dr. Robert Charette die in früheren Veröffentlichungen beschriebenen Lean-Ideen in seinem Buch „Lean Software Development“.

Der Begriff Agile wurde erst mit der Veröffentlichung von „The Agile Manifesto“ im Jahr 2001 allgemein übernommen. Die Begriffe „Agile“ und „Lean“ wurden beide von westlichen Technologieexperten oder Akademikern geprägt, die sich auf das Toyota-Produktionssystem bezogen (dazu später mehr).

Wir mögen dafür vielleicht etwas Kritik einstecken, aber in diesem Sinne sind die Begriffe „Lean“ und „Agile“ eigentlich nicht so wichtig. Zwei Begriffe, die auf denselben Prinzipien beruhen, tragen zur Verwirrung in diesem Bereich bei. Abgesehen davon ist dies die Terminologie, die die Branche übernommen hat, also werden wir sie auch in Zukunft verwenden.

Eine weitere Quelle der Verwirrung ist der Zeitplan. Dr. Robert Charette stellte seine Ideen zur schlanken Softwareentwicklung Anfang bis Mitte der 90er Jahre vor. Der taktische Zweck und die 12 Prinzipien seines Lean Development-Ansatzes wurden 1998 in einem Artikel mit dem Titel „Lean Development“ beschrieben, fast drei Jahre vor dem „Agilen Manifest“. Ein Beleg für die Überschneidungen zwischen Lean und Agile ist, dass dieser Artikel von Jim Highsmith geschrieben wurde, der später einer der Hauptbegründer der Agile-Bewegung wurde. Highsmiths Artikel fand jedoch keine weite Verbreitung, und erst 2003 schrieb Charette selbst eine ausführlichere Erklärung seines schlanken Entwicklungsansatzes in dem Forschungsbericht Challenging the Fundamental Notions of Software Development“.

In einem E-Mail-Austausch mit Dr. Charette wies er darauf hin, dass sein Konzept der schlanken Entwicklung für die Organisationsebene im Softwarebereich gedacht war:

Mein Konzept entstand aus der strategischen und operativen Notwendigkeit, den Wert der IT für das Unternehmen zu verbessern, und ich bin dies aus der Perspektive des Risikomanagements angegangen.
-Dr. Robert N. Charette

Dies unterscheidet sich geringfügig von Agile, das zunächst als eine „bessere Art der Softwareentwicklung“ vorgeschlagen wurde, heute aber auf verschiedene Projekte und Managementmethoden angewendet wird.

2003 war auch das Jahr, in dem die Poppendiecks Lean Software Development veröffentlichten: An Agile Toolkit. In diesem Buch werden sieben Prinzipien der schlanken Entwicklung beschrieben, die direkt mit den sieben Formen der Verschwendung in der schlanken Fertigung korrelieren.

Das Buch der Poppendiecks hat gleichzeitig Lean als Softwareentwicklungsmethode gestärkt und die Unterscheidung zwischen Lean und Agile verwischt, indem Lean als ergänzende Methode innerhalb von Agile vorgeschlagen wurde. Zum Zeitpunkt der Veröffentlichung wurde das Buch als jüngste Publikation der Reihe „Agile Software Development Series“ verkauft.

Heute gelten die zahlreichen Werke der Poppendiecks zu diesem Thema als Pflichtlektüre für Lean- und „aufstrebende Lean“-Softwareentwickler.

Divergenz in der Anwendung

Einer der Hauptunterschiede zwischen Lean und Agile besteht laut Dr. Charette darin, dass Agile von unten nach oben arbeitet, während Lean von oben nach unten angelegt ist. Dies zeigt sich in der End-to-End-Struktur (E2E) von Lean und dem von den Poppendiecks vorgeschlagenen Prinzip „See the Whole“. Im Folgenden werden diese Prinzipien in der Praxis des Wertstrom-Mappings erläutert.

Wertstrom-Mapping

Um das Prinzip „See the Whole“ zu verwirklichen, beschreiben die Poppendiecks eine Methode des Wertstrom-Mappings, mit der die wertschöpfenden Aktivitäten den nicht wertschöpfenden Aktivitäten im gesamten End-to-End-Entwicklungsprozess gegenübergestellt werden.

Das Wertstrom-Mapping analysiert den Entwicklungszyklus vom Eingang einer Anforderung bis zur Lieferung an den Kunden. Das Ziel ist es, die Verschwendung von Lagerbeständen und Wartezeiten (Verzögerungen in der Produktion) zu identifizieren und neue Praktiken zu erforschen, um den Arbeitsfortschritt (WIP) und die Durchlaufzeit zu reduzieren.

Nach Ansicht der Poppendiecks ist die Abbildung Ihres Wertstroms eine einfache Übung, für die nur ein Stift und ein Blatt Papier erforderlich sind. Der Prozess läuft wie folgt ab:

1. Kartieren Sie Ihren aktuellen Wertstrom (beginnend mit einer Anforderung und einem Zeitplan für die Aktionen auf dem Weg zur Lieferung)
2. Analysieren Sie die größte Ursache für Verschwendung (Was hält den Arbeitsfortschritt auf?)
3. Entwickeln Sie einen Plan, um diese Verschwendung zu halbieren
4. Erstellen Sie eine zukünftige Wertstromkarte

Das agile Paradigma, wie es im „Agilen Manifest“ dargelegt ist, bevorzugt kurze Iterationszyklen und häufige Lieferungen gegenüber einer ganzheitlichen End-to-End-Sicht. Der E2E-Fokus ist daher einzigartig bei Lean. Tatsächlich ist es das E2E-Konstrukt, das dafür sorgt, dass Lean (und nicht Agile) häufiger als Organisationsstruktur und Managementstil eingesetzt wird.

Die End-to-End-Betrachtung erfordert, dass die gesamte Organisation daran beteiligt ist, um Verschwendung zu vermeiden. Dies entspricht dem von Dr. Charette für sein ursprüngliches Lean-Development-Konzept formulierten Ziel:

Lean Development ist eine Philosophie, eine Sicht- und Denkweise über IT und ihre Beziehung zu einer Organisation, ebenso wie es ein Entwicklungsansatz ist.

Lean Kanban vs. Agile Kanban

Beide, Lean und Agile, haben das TPS Kanban System mit leichten Variationen übernommen. Toyotas Kanban-System wurde entwickelt, um den Work-in-Progress zu begrenzen.

Im Gegensatz zur traditionellen „Push-Fertigung“, bei der die Bestände in den nächsten Prozessschritt verschoben werden, zieht Kanban erst dann neues Material in die Produktion ein, wenn das aktuelle Teil verarbeitet wurde und Komponenten nachgefüllt werden müssen.

Kanban-Karten werden zu Nachschubaufträgen und werden an den vorherigen Produktionsschritt zurückgeschickt. Dadurch wird der Arbeitsfortschritt minimiert und ungenutzte Bestände werden reduziert.

In der Softwareentwicklung wird anstelle der Weitergabe von Kanban-Karten von einem Fertigungsschritt zurück zum vorherigen ein Kanban-Board verwendet. Dabei werden Haftnotizen verwendet, meist um Anforderungen in Bearbeitung darzustellen.

Nach dem Kapitel von Kai Petersen in Modern Software Engineering Concepts and Practices: Advanced Approaches, verwenden sowohl Agile als auch Lean eine priorisierte Anforderungsliste, aus der Aufgaben abgeleitet werden.

Im Gegensatz zu Agile, das Iterationszyklen von fester Dauer verwendet, um die Entwicklungszeit zu begrenzen und das Kanban-Board zu steuern, begrenzt Lean die Anzahl der zu einem bestimmten Zeitpunkt zulässigen Aufgaben. Auf diese Weise kann Lean sein Hauptziel, die WIP zu begrenzen, erfüllen und gleichzeitig die Durchlaufzeit genauer messen und Verschwendung in der Produktion aufdecken. Sobald eine Aufgabe abgeschlossen ist, kann eine neue Aufgabe aus der priorisierten Liste gezogen werden. Während Lean das Konzept des kontinuierlichen Flusses verwendet, beginnt Agile jede neue Iteration mit einem neuen Board.

Einige Teams haben die Vorteile beider Ansätze erkannt und beginnen, eine hybride Methode zu verwenden, die als Scrumban bekannt ist.

Dies sind nur zwei der subtilen Unterschiede in den Ansätzen, die Lean und Agile verfolgen, um gemeinsame Ziele zu erreichen. Ein weiterer Artikel auf Codementor befasst sich mit den Einsatzmöglichkeiten und Anwendungen von Lean und Agile.

In der Praxis ist es unwichtig, ob Ihr Team einen sogenannten „Agile“- oder einen „Lean“-Ansatz verfolgt. Wichtig ist, dass Sie die richtigen Praktiken finden, um Ihre Arbeitsabläufe zu optimieren und Ihren Kunden beständig einen Mehrwert zu liefern, was beide Methoden als oberstes Ziel ansehen.

Die TPS-Verbindung

Was hat das alles mit dem Toyota Production System zu tun? So ziemlich alles. Die Erfinder von Agile und Lean wurden stark vom TPS beeinflusst, wie Womack et. al. in The Machine That Changed the World beschreiben. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. Das Unternehmen konnte nicht darauf hoffen, nach dem Detroiter Modell der Massenproduktion zu überleben.

Unter diesen Bedingungen machten sich Taiichi Ohno und Kiichiro Toyoda daran, rentabel zu bleiben, indem sie die Verschwendung in der Produktion beseitigten, die Vorlaufzeit verkürzten und nur das produzierten, was die Kunden brauchten, was auch als Just-in-Time-Fertigung (JIT) bekannt ist.

Um die Verschwendung zu beseitigen, beschloss Ohno, nur das herzustellen, was gebraucht wurde, wann es gebraucht wurde und nur in der Menge, in der es gebraucht wurde.

Der iterative Prozess von Lean und Agile, der sich auf die Minimierung der Entwicklung von Funktionen und die Maximierung der Lieferung von Aktualisierungen konzentriert, spiegelt direkt Toyotas Just-in-Time-Fertigung wider.

Jidoka

Jidoka (自働化) kann als Automatisierung mit menschlichem Einschlag übersetzt werden und wird manchmal auch als „intelligente Automatisierung“ bezeichnet. Jidoka spielt eine wichtige Rolle bei der Beseitigung von Verschwendung in der Produktion, indem es Maschinen unabhängiger macht, wodurch Menschen eine aktivere Rolle in der Produktion spielen können und die menschliche Kreativität freigesetzt wird.

Jidoka setzt auf intelligente Maschinen, die bei Unregelmäßigkeiten automatisch anhalten. Menschliche Arbeitskräfte können dann das Problem beheben und verhindern, dass Fehler im Produktionsprozess weitergegeben werden.

Jidoka befähigt auch jeden Mitarbeiter, die Produktionslinie anzuhalten, wenn ein Problem entdeckt wird. Das Prinzip umfasst einen vierstufigen Prozess, um die Verschwendung fehlerhafter Produkte zu beseitigen:

1. Erkennen der Anomalie
2. Produktionsstopp
3. Beheben oder korrigieren Sie den unmittelbaren Zustand
4. Untersuchen Sie die Grundursache und beheben Sie die Situation

Das Jidoka-Konzept zeigt sich auch darin, dass der Schwerpunkt bei Lean und Agile auf frühzeitigen und häufigen Tests liegt, um Fehler auszumerzen, und dass der Schwerpunkt auf der Konsultation der Kunden liegt, um die Beschwerden der Benutzer zu ermitteln.

Verschwendung von TPS im Kontext der Softwareentwicklung

Um die JIT-Fertigung zu erreichen, beschrieb Taiichi Ohno sieben Formen der Verschwendung, die beseitigt werden müssen. Nummer acht wurde später hinzugefügt. Wenn man sich die Werte, Ziele und Prinzipien von Agile und Lean genauer ansieht, erkennt man, dass sie darauf ausgerichtet sind, die acht Verschwendungsarten von TPS zu verhindern. In ihrem 2003 erschienenen Buch Lean Software Development: An Agile Toolkit stellen die Poppendiecks die TPS-Verschwendungen im Kontext der Softwareentwicklung vor.

1. The Waste of Overproduction. Die Verschwendung durch Überproduktion ist einer der Hauptgründe, warum die Wasserfallmethode aufgegeben wurde. Überproduktion wird als zusätzlicher Code für Funktionen angesehen, die nicht angefordert wurden und die der Kunde möglicherweise nicht will.

Dies spiegelt sich in den folgenden Prinzipien wider:

Agile ⟶ Einfachheit
Charette’s Lean⟶ Minimalismus
Poppendiecks‘ Lean ⟶ Verschwendung eliminieren

2. Die Verschwendung des Wartens. In der JIT-Fertigung ist es Verschwendung, auf eine untätige Maschine oder einen untätigen Arbeiter zu warten. Bei der Softwareentwicklung ist es Verschwendung, auf ein Team mit Überkapazitäten zu warten. Wenn es Verzögerungen in der Produktion gibt, die dazu führen, dass ein Team in Bereitschaft ist oder der Kunde auf die Lieferung warten muss, liegt Verschwendung vor.

Die passenden Prinzipien sind folgende:

Agile ⟶ häufige Zyklen
Charette’s Lean ⟶ ⅓ der Zeit (Ziel von LSD), 80% Lösung heute
Poppendieck’s Lean⟶ so schnell wie möglich liefern

3. Die Verschwendung von Transport. In der Softwareentwicklung wird Transport mit „Aufgabenwechsel“ übersetzt. Zu viele Übergaben oder Mitarbeiter, die mehreren Teams zugewiesen sind und übermäßiges Multitasking verlangen, sind ineffizient und eine Verschwendung.

Zugehörige Prinzipien:

Agile ⟶ Zusammenarbeit mit Stakeholdern, selbstorganisierende Teams, eine Kultur des
Vertrauens, der Unterstützung und der Motivation
Charette’s Lean ⟶ Teamarbeit
Poppendiecks Lean ⟶ Befähigung des Teams

4. Die Verschwendung der Überbearbeitung. Dabei handelt es sich einfach um zusätzliche Prozesse, die nicht wirklich benötigt werden, um dem Kunden einen Mehrwert zu liefern. Das wichtigste Beispiel ist die Dokumentation. Übermäßige Dokumentation für unflexible Prozesse ist ebenso wenig wertvoll wie übermäßig detaillierte Benutzerhandbücher, die sich auf ein oder zwei Seiten zusammenfassen lassen. Dokumentation ist zeitaufwendig, bietet dem Endbenutzer aber nur begrenzten Wert.

Zugehörige Prinzipien:

Agile ⟶ Einfachheit, funktionierende Software als Maßstab
Charette’s Lean ⟶ Minimalismus
Poppendiecks‘ Lean ⟶ Verschwendung eliminieren

5. The Waste of Inventory. Bestandsvergeudung ist Work-in-Progress, für die eine Investition getätigt wurde, die aber bis zur Fertigstellung keinen Wert hat. Mit anderen Worten: Unvollständige Software bietet dem Nutzer keinen Wert. Lean und Agile legen Wert auf schnelle und häufige Lieferungen, wobei der Schwerpunkt auf häufigen iterativen Zyklen und der Lieferung funktionierender Software liegt.

Zugehörige Prinzipien:

Agile ⟶ Kundenzufriedenheit (durch frühe und häufige Kunden
Lieferung)
Charette’s Lean ⟶ 80% Lösung heute
Poppendieck’s Lean ⟶ so schnell wie möglich liefern

6. Die Verschwendung der Bewegung. Waste of Movement ist ein übermäßiger Aufwand, um Informationen zu erhalten oder Fragen zu beantworten. Dies ist häufig der Fall, wenn die Teams nicht zusammenarbeiten, wenn Aufgaben abgeschlossen und die Ergebnisse nicht sofort allen Beteiligten zur Verfügung gestellt werden oder wenn die Beteiligten nicht ohne Weiteres für Konsultationen zur Verfügung stehen.

Zugehörige Prinzipien:

Agile ⟶ Zusammenarbeit mit den Beteiligten, Kommunikation von Angesicht zu Angesicht
Charette’s Lean ⟶ Kundenbeteiligung, Teamarbeit
Poppendiecks‘ Lean ⟶ Verschwendung beseitigen

7. Die Verschwendung von Mängeln. Wie in der Fertigung stellt die Produktion von fehlerhafter oder fehlerhafter Software eine verschwendete Investition für das Unternehmen dar. Je schneller ein Fehler entdeckt wird, desto eher wird die Verschwendung gemindert. Viele Agile- und Lean-Prinzipien zielen darauf ab, die Verschwendung von Fehlern zu stoppen. Um Fehler zu reduzieren, legen alle drei Methoden großen Wert auf frühzeitige und häufige Tests.

Zugehörige Prinzipien:

Agile ⟶ technische Exzellenz, funktionierende Software als Maßstab
Charette’s Lean ⟶ Kundenzufriedenheit
Poppendiecks‘ Lean⟶ amplify learning

8. Die Verschwendung ungenutzter Mitarbeiterkreativität. In der Softwareentwicklung resultiert ungenutzte Kreativität aus einer starren Roadmap und mangelnder menschlicher Zusammenarbeit. Genau wie Jidoka (自働化) versuchen Agile und Lean, die menschliche Zusammenarbeit und Innovation zu maximieren, um die besten Ergebnisse aus der Technologie herauszuholen.

Übereinstimmende Prinzipien:

Agile ⟶ Zusammenarbeit mit Stakeholdern, Reflexion im Team
Charette’s Lean ⟶ „ungeschriebenes“ 13. Prinzip der Zufriedenheit durch
Arbeit
Poppendiecks‘ Lean ⟶ Verstärkung des Lernens

TPS-Werte in der Softwareentwicklungsmethodik

Viele der Kernwerte, die TPS ausmachen, spiegeln sich auch in den agilen und schlanken Softwareentwicklungsmethoden wider.

Kaizen (改善) bedeutet übersetzt „kontinuierliche Verbesserung“. Mit flexiblen, iterativen, kundenorientierten Modellen ist die kontinuierliche Verbesserung vielleicht der wichtigste Wert der agilen und schlanken Softwareentwicklungsmethoden.

Hansei (反省) bedeutet Selbstreflexion. Als Mittel zur Verbesserung der Effizienz nimmt das Agile Manifest die Selbstreflexion des Teams direkt als 12. Prinzip auf. Bei der Einführung seines Lean-Development-Modells fordert Dr. Charette die Leser auf, über alle aktuellen Annahmen nachzudenken, die die von ihnen verwendeten Prozesse bestimmen, um so einen ersten Schritt zu besseren Prozessen zu machen. Auch das Prinzip der Poppendiecks, das Lernen zu verstärken, kann als Hansei betrachtet werden.

Respekt vor dem Menschen (尊重) ist für alle drei Paradigmen von zentraler Bedeutung. Der erste Wert des „Agilen Manifests“ besteht darin, „Individuen und Interaktionen über Prozesse und Werkzeuge zu stellen“

Respekt für Menschen taucht auch in Dr. Charettes Aussage auf, wie wichtig es ist, dass der Einzelne durch seine Arbeit Zufriedenheit erfährt, und in Poppendiecks Lean-Prinzip der Befähigung von Teams. Dieser Wert erkennt an, dass Menschen innovativer und effizienter arbeiten, wenn sie in die Entscheidungsfindung und die Verbesserung ihres Arbeitsumfelds einbezogen werden.

Seiri (整理) ist das Prinzip, das die Verschwendung widerspiegelt. Seiri besagt, dass alles, was unnötig ist, entfernt werden sollte. Dies umfasst alle ursprünglichen sieben Verschwendungen des TPS, für die wir bereits die parallele Verschwendung in der Softwareentwicklungsumgebung identifiziert haben.

Gengchi Genbutsu (現地現物) bedeutet wörtlich übersetzt „tatsächlicher Ort, tatsächliche Sache“. In der Praxis bedeutet dies „inspizieren, um zu verstehen“. Wenn es ein Problem im Produktionsprozess gibt, sollte der Manager zur Quelle gehen, um das Problem zu verstehen und herauszufinden, wie es zu lösen ist.

In der Softwareentwicklung manifestiert sich dieser Wert in der Betonung kurzer Iterationszyklen, frühzeitiger Tests und der Zusammenarbeit mit dem Kunden, damit die Softwareingenieure funktionierende Software entwickeln können, die die Benutzer tatsächlich wollen.

Fazit

Wie wir in den ersten Absätzen dieses Beitrags erwähnt haben, ist die Lean-Methodik weniger gut bekannt und wird oft als eine agile Praxis betrachtet.

Lean hat eine direktere Beziehung zum Toyota-Produktionssystem und wurde zunächst als eine Reihe von Methoden und Praktiken für die Unternehmensführung vorgeschlagen und erst später auf die Softwareentwicklung angewendet. Agile hingegen wurde von engagierten Fachleuten speziell für die Softwareentwicklung entwickelt.

Nachdem wir den gemeinsamen Hintergrund und die allgemeinen Grundsätze dieser beiden Methoden näher beleuchtet haben, können wir feststellen, dass diese beiden Paradigmen mehr Gemeinsamkeiten als Unterschiede aufweisen.

Martin Fowler, einer der Hauptautoren von „The Agile Manifesto“, der auch eng mit den Poppendiecks zusammengearbeitet hat, hat darauf hingewiesen, dass Lean und Agile sich nicht gegenseitig ausschließen:

Lean und Agile sind in der Software-Welt tief miteinander verwoben. Man kann nicht wirklich davon sprechen, dass sie alternativ sind:

1. Die 12 Prinzipien von Charette’s Lean Software Development wurden erstmals in Jim Highsmiths Artikel „Lean Development“ im Jahr 1998 beschrieben. Später wurde dies in Dr. Charettes eigenem Artikel „Challenging the Fundamental Notions of Software Development“ ︎

ausgearbeitet.