Lean Management vs. Agile? Was für ein Quatsch!

Lean Management vs. Agile? Was für ein Quatsch!

Heutzutage erlebt das Thema Agilität eine hohe Aufmerksamkeit – es scheint das Allheilmittel für organisatorische Probleme aller Art zu sein. So hört man von manchen Zeitgenossen die Aussage, dass diese nun kein Lean mehr brauchen, da man jetzt agil sei. Diese Denkweise ist nicht nur historisch gröbster Unfug, sie blendet auch viele weitere Aspekte aus. Daher ist dieser Beitrag nichts weniger als der Versuch einer ersten Einordnung

#leanmagazin
am 22. 10. 2020 in LeanMagazin von Mark Lambertz


Gleich zu Beginn muss ich vorwegnehmen, dass die Diskussion um Lean vs. Agile häufig auf einen Methodenvergleich reduziert wird, welcher das berühmt berüchtigte Mindset des Lean oder Agile nicht berücksichtigt. Dies ist fatal, da das Mindset logischerweise die fundamentalen Prämissen des Mindsets beschreibt, auf deren Basis sich dann die unterschiedlichen Methoden und Praktiken entwickelt haben. Zur Darstellung der jeweiligen Sichtweisen möchte ich zunächst in die Geschichte schauen und aufführen, in welchen Umfeldern und zu welchen Zeiten sich diese beiden Denkschulen nach meinem Verständnis herausgebildet haben.

Lean, Japan und der 2. Weltkrieg

Ohne den Sachkundigen langweilen zu wollen sei trotzdem noch einmal daran erinnert, dass die Ursprünge von Lean in die Zeit zurückreichen, in der Japan nach dem 2. Weltkrieg am Boden lag und mit einem heftigen Ressourcenmangel zu kämpfen hatte (streng genommen geht die Geschichte bis zum Ururgroßvater der Familie Toyoda zurück). Des Weiteren ist von je her die wirtschaftlich nutzbare Fläche im Land relativ begrenzt gewesen, sodass ein weiterer Engpass ins Spiel kam. All diese Rahmenbedingungen zwangen japanische Unternehmer dazu extrem bewusst mit Ressourcen umzugehen und Verschwendung jedweder Form zu vermeiden. Gleichzeitig verlangt(e) das japanische Ethos rund um den Begriff der Qualität keine Abstriche – die Ausrichtung auf die Zufriedenheit des Kunden war und ist das oberste Gebot. Daran schließt wiederum die soziale Kultur des Miteinander an, in welcher das Kollektiv über den Bedürfnissen des Einzelnen steht und das aus westlicher Sicht klischeehafte „Gesicht wahren“ eine starke soziale Bindung und Verantwortung hervorruft. Das „gute Verhalten“ und die Vorbildfunktion ist auf allen Ebenen anzutreffen ­– es herrscht zuweilen ein erheblicher gesellschaftlicher Erwartungsdruck. Dies sind alles Vorrausetzungen, welche die Entwicklung des Lean Thinking enorm begünstigt haben.

Abschließend sei auf den entscheidenden Umstand verwiesen, dass Lean Management im Umfeld des produzierenden Gewerbes entstand. Es ist eine Welt, die von Maschinen, Fabriken und messbaren Größen wie Stück, Losgröße oder Liefertreue bestimmt ist.

Agile, USA, Ende der 80er Jahre

Die Ursprünge der agilen Methoden, welche heutzutage im Schlagwort-Dschungel kursieren, sind bereits Ende der 80er im legendären Software-Unternehmen Borland zu finden. Damals herrschte bei Programmierern, Projektleitern und letztendlich auch bei den Kunden ein großer Frust darüber, dass die sorgfältigst geplante und programmierte Software nicht den Wünschen des Kunden entsprachen. Es herrschte Missverständnisse allerorten und ungeklärte Erwartungshaltungen verursachten stets große Verzögerungen und entsprechende Kosten. Dabei meinte man doch alles richtig zu machen, in dem man stets einen vorbildlichen Wasserfallprozess aufgesetzt hatte.

Abbildung 1: Typischer Wasser Fall

Zur Ehrenrettung des Wasserfalls ist auch hier wieder eine historische Einordung wichtig. Zum einen ist die Grundidee des Wasserfalls ungefähr zur gleichen Zeit wie die des PDCA-Zyklus entstanden (Boehm, 1956), auch wenn der Wasserfall in seiner bekannten Form erst 1970 von Boyce in einem Fachartikel veröffentlicht wurde. Des Weiteren haben sowohl Boehm wie auch Boyce stets betont, dass der im Wasserfall vorgegebene Fluss nicht als lineare Abfolge zu verstehen ist und mindestens zwei Mal durchlaufen werden muss – dass also ein Prototyp VOR der eigentlichen Programmierung einer produktiven Anwendung erstellt werden sollte. Pikanterweise schrieb Boyce höchstpersönlich, dass der Wasserfall-Ansatz nicht für große Software-Projekte geeignet ist, da es bei diesen zu viele unbekannte Variablen gibt.

Somit lässt sich auch der Wasserfall mit der agilen Welt versöhnen, denn ein zirkuläres Vorgehen war von jeher angedacht. Daher arbeitet auch die Scrum-Methodik in der Softwareentwicklung mit den wesentlichen Schritten des Wasserfalls, nur eben in kürzeren Abständen (sogenannten Sprints). Damit dies am besten gelingt, werden die zu erstellenden Schritte kleiner gehalten sind, um die zur Verfügung stehende Zeit bestmöglich zu nutzen (und möglichst wenig Verschwendung zu generieren). Man könnte also sagen, dass die „gedanklichen Losgrößen und Stück“ klein gehalten werden, um im Fall eines Irrtums nur wenige Werte vernichtet zu haben.

Das letzte Argument zur Ehrenrettung des Wasserfalls bezieht sich auf die „Konstruktion“ einer Software. Es ist einfach nicht möglich eine Software (oder einen Teil davon) zu testen, bevor diese programmiert wurde. Genauso wenig kann man eine Software nicht programmieren, wenn die Anforderungen und das gemeinsame Verständnis hinsichtlich der Funktionen nicht geklärt sind. Gleiches gilt auch für den Aufbau eines Billy-Regals: Es wäre zwar möglich mit der Rückwand zu beginnen, aber es macht aufgrund der Konstruktion eines Regals keinen Sinn, mit diesem Schritt zu beginnen. Aus der Beschaffenheit eines Objekts ergibt sich häufig eine Schrittfolge, wenn man dieses „Ding“ herstellen will.

In kurz: Der Wasserfall wurde vom linearen Denken des damaligen Managements gehijackt und seines Zwecks entfremdet. Dann kamen noch die Controller ins Spiel kamen und fertig war die Laube.

Aus diesen Schmerzen heraus entstand die Einsicht, nicht mehr linear zu planen, sondern im Kern den bekannten Demmingkreis des PDCA zu durchlaufen. Ein schrittweises Vorgehen (inkrementelle Entwicklung) war der einzige Ausweg aus dem Teufelskreis von steigender Frustration und ausufernden Kosten. Obgleich sich diverse Praktiken in den frühen 90er Jahren entwickeltet hatten, so bekam der Begriff der Agilität eine besondere Bedeutung, als dieser im Rahmen eines informellen Treffens als Manifest ins Netz gestellt wurde. Die Rede ist vom agilen Manifest, welches 2001 in Boulder (Colorado) von Vertretern verschiedener agiler Praktiken verfasst wurde.

Die vier Kernwerte des agilen Manifests lauten (allgemein übersetzt für die Wissensarbeit):

  • Menschen und Interaktionen sind im Zweifel wichtiger als Prozesse und Werkzeuge.
  • Funktionierende Ergebnisse sind im Zweifel wichtiger als eine überbordende Dokumentation.
  • Die Zusammenarbeit mit dem Kunden ist im Zweifel wichtiger als Vertragsverhandlungen.
  • Die Anpassung an veränderte Rahmenbedingungen ist wichtiger im Zweifel als das sture befolgen eines Plans.

Vereinfacht gesagt geht es im agilen Manifest darum, den Kunden glücklich zu machen, in dem man kontinuierlich Werte liefert und die Fähigkeiten eines Teams bestmöglich einsetzt. Dabei geht es bei den Werten nicht um ein Entweder-Oder-Denken, sondern darum, dass zum Beispiel funktionierende Ergebnisse wichtiger sind, als bürokratische Monster aufzubauen und sinnlose PowerPoint-Folien zu schrauben. Ein weiteres Merkmal des Manifests bezieht sich auf die Anpassungsfähigkeit eines Systems. Die schnelle Adaption an sich verändernde Umweltbedingungen gehört zum Tagesgeschäft des Agile Thinking.

Was haben Lean Management und Agile gemeinsam?

Die folgende Aufzählung führt verschiedene Eigenschaften auf, die das Lean- und Agile Thinking miteinander verbinden:

  • Respekt für die Menschen
  • Fokus auf die Schaffung von Wert für den Kunden
  • Fluss in der Zusammenarbeit herstellen (oder neudeutsch der „Flow“)
  • Das finden und beseitigen von Verschwendung und Engpässen
  • Meistern von Taktzyklen
  • Messbarkeit und Kennzahlen
  • Und dramaturgisch ans Ende gesetzt: Permanentes Lernen und Reflexion – ganz egal, ob es im Shopfloor am Teamboard stattfindet oder in einem agilisierten Controlling-Team, welches sogenannte Reviews und Retros nutzt.

Man könnte diese Auflistung auch als die Schnittmenge der Intentionen der beiden Denkschulen bezeichnen. Dabei kann diese Aufzählung nicht den Anspruch auf Vollständigkeit erheben, aber hoffentlich eine Tendenz aufzeigen: Die konsequente Kundenorientierung eint beide Domänen. Jeder der in der Visualisierung gezeigten Aspekte ist dazu gedacht, die Lieferung von Werten für den Kunden zu verbessern – dies ist der wichtigste Zweck eines lebensfähigen Systems. Egal ob es sich per Lean oder Agile organisiert.

Kreislauf aus Kreisläufen

Zur Verdeutlichung des wichtigsten Wesenszugs von Lean und Agile möchte ich noch einmal auf die Zirkularität zurückkommen. Die populärste Methodik in der agilen Welt nennt sich Scrum und sieht vereinfacht folgendermaßen aus:

Abbildung 2: Typische Darstellung des Scrum-Prozesses mit einigen wichtigen Ereignissen und Artefakten

Dem geübten Leanfreak springt es hoffentlich ins Auge: Scrum ist im Kern PDCA!

Abbildung 3: Der bekannte PDCA-Zyklus, auch als Demming-Kreis bekannt

Beiden Ansätzen ist also gemein durch schrittweise Verbesserungen zu lernen, um ein Gesamtoptimum in einem übergreifenden Produktionsprozess zu erreichen. Somit habe ich hoffentlich vermittelt, warum es Quatsch ist, Lean und Agile als Gegensätze zu betrachten. Vielmehr sollte es darum gehen, die beiden Denkschulen als zwei Seiten der gleichen Medaille zu sehen und die jeweiligen Stärken, bezogen auf den Problemkontext, für sich zu nutzen.

Im zweiten Teil der Serie möchte ich Ihnen einen Ansatz vorstellen, um (frei nach Gerhard Wohland) Lean und Agile sinnvoll zu unterscheiden, ohne sie zu trennen.



Kommentare

Bisher hat niemand einen Kommentar hinterlassen.

Kommentar schreiben

Melde Dich an, um einen Kommentar zu hinterlassen.

Teilen