Um Agilität historisch richtig einordnen zu können, muss man bis zu den Prinzipien des Lean Managements zurückzugehen. Agilität im Sinne des agilen Manifests von 2001 kann so als Anwendung der fünf Lean Prinzipien auf Softwareentwicklung verstanden werden. Der Fokus von Agilität liegt auf der schnellen Lieferung von Kundenwert durch funktionierende Software. Und der optimale Fluss dafür entsteht im interdisziplinären selbstorganisierten Team, das den kompletten Wertstrom von der Idee bis zum Betrieb der Software abdeckt.
Kundenwert definieren
Lean Management beginnt immer am Ende. Ein erster und sehr wichtiger Schritt aller Lean Überlegungen ist es, den Wert aus Sicht des Kunden zu erkennen und zu definieren. Was braucht der Kunde wirklich, was schätzt er und wofür ist er am Ende bereit zu bezahlen?
Don’t find customers for your products, find products for your customers.
Seth Godin
Agilität im Sinne des Manifests für agile Softwareentwicklung stellt den Kundennutzen ebenfalls ins Zentrum, nähert sich der Frage nach dem richtigen Nutzen aber empirisch und weniger analytisch als es dieses zugrunde liegende Lean-Prinzip suggeriert. Agile Entwicklung heißt in kurzen Abständen ein benutzbares Produktinkrement zu liefern. Nicht nur, weil das auch schneller einen Nutzen erzeugt, sondern auch und gerade, um dadurch zu lernen, ob und wie gut der Kunde damit zufrieden ist. Agil arbeitende Organisationen wie Amazon oder Spotify probieren ständig neue Ideen live an uns aus und lernen dadurch Schritt für Schritt was ihre Kunden schätzen und was nicht und wie sie ihr Produkt anpassen und verbessern könnten.
Wertstrom identifizieren
Ausgehend vom Kundenwert fokussiert dieses zweite Prinzip auf alle Prozesse, Aktivitäten und Zwischenergebnisse zur Herstellung des Kundenwerts. Ziel ist es dabei, sich auf die wertschöpfenden Prozesse zu konzentrieren und unnötigen Aufwand (Muda im Japanischen, was fälschlicherweise oft mit Verschwendung übersetzt wurde) zu vermeiden.
The most dangerous kind of waste is the waste we do not recognize.
Shigeo Shingo
Diese Suche nach dem optimalen Wertstrom für Softwareentwicklung hat die Autoren des Manifests im Jahr 2001 in Utah zusammengebracht. Sie empfanden die damals immer schwergewichtiger werdenden Entwicklungsmodelle für Software wie beispielsweise den Rational Unified Process oder das V‑Modell als (vorsichtig ausgedrückt) nicht optimal gestaltete Wertströme. Genau darum legt das Manifest so den Fokus auf funktionierende Software mehr als auf umfassende Dokumentation und stellt Individuen und Interaktionen über Prozesse und Werkzeuge.
Fluss optimieren
Das Fluss-Prinzip ist es wesentliches Gestaltungsprinzip des Lean Managements. Gemeint ist damit der kontinuierliche und geglättete Ablauf der Produktion entlang des Wertstroms. In vielen Fällen ist dieser Fluss nämlich durch Grenzen in der Organisation unterbrochen, was zu lokaler Optimierung und unnötigem Aufwand in Form von Lagern für Zwischen- oder Endergebnisse führt.
Alles fließt, nichts bleibt.
Heraklit
Die Erkenntnis der Autoren des Manifests für agile Softwareentwicklung war es, dass der optimale Fluss für Softwareentwicklung durch ein interdisziplinär besetztes und selbstorganisiertes Team entsteht, das über den gesamten Wertstrom von der Idee über die Programmierung bis zum Betrieb der Software ohne Unterbrechungen und Übergaben eng mit dem Kunden zusammenarbeitet. Agile Entwicklung ist im Kern ein kontinuierlicher Fluss von Produktinkrementen mit denen das Team Schritt für Schritt das Problemfeld und den Lösungsraum exploriert.
Pull-Prinzip umsetzen
In der Lean Management Philosophie wird die Produktion vom Kunden aus angestoßen. Die Produkte werden vom Kunden aus gesehen durch die Produktion „gezogen“ (pull) und nicht mittels Planungsvorgaben und Produktionszielen durch die Produktion „gedrückt“ (push).
The more inventory a company has, the less likely they will have what they need.
Taiichi Ōno
Agile Methoden und Rahmenwerke können ihre Verbindung zum Pull-Prinzip gar nicht verleugnen. In Scrum beispielsweise legt der Product-Owner als Repräsentant des Kunden fest, was als nächstes gebraucht wird. Das Entwicklungsteam zieht sich dann in dieser Reihenfolge so viele Elemente des Backlogs wie es im nächsten Sprint umsetzen kann. Und innerhalb des Sprints wird im Detail auf einem Kanban-Board gearbeitet, wo auch wieder das Pull-Prinzip gilt und neue Aufgaben erst nachgezogen werden wenn andere abgeschlossen sind: Start finishing – stop starting.
Kontinuierlich verbessern
Im Lean Management sind alle Mitarbeiter aufgefordert kontinuierlich Abläufe zu hinterfragen und an ihrer Verbesserung zu arbeiten. Die Logik dahinter ist einleuchtend und eine deutliche Abkehr von der vorherrschenden tayloristischen Denkweise: Diejenigen die im Prozess arbeiten und nicht ihre Manager, kennen die Abläufe am besten und sind folglich diejenigen die sie am besten optimieren können.
Something is wrong if workers do not look around each day, find things that are tedious or boring, and then rewrite the procedures. Even last month’s manual should be out of date.
Taiichi Ōno
Auch dieses Prinzip findet sich im Manifest für agile Softwareentwicklung fast unverändert wieder. Dort heißt es in den Prinzipien, dass das selbstorganisierte Team In regelmäßigen Abständen reflektiert, wie es effektiver werden kann und sein Verhalten entsprechend anpasst. Im Scrum gibt es mit der Sprint-Retrospektive sogar ein eigenes Event dafür. Was kleinen für das Team und seine Arbeit gilt, trifft auf agile Organisationen auch im großen zu: Standards entstehen dort emergent aus der Zusammenarbeit und werden nicht mehr als Blaupause zentral erdacht und ausgerollt. Aber eigentlich ist auch das nichts Neues, sondern findet sich schon bei Taiichi Ōno, dem Erfinder des Toyota Produktionssystems.
Standards should not be forced down from above but rather set by the production workers themselves.
Taiichi Ōno
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
5 Kommentare
Hallo Marcus,
wiedereinmal eine tolle Zusammenfassung.
Jeff Sutherland beschreibt die Geschichte hinter Scrum im Buch „Scrum: The Art of Doing Twice the Work in Half the Time“ sehr schön und zeigt auch den Zusammenhang zum Lean Management. Beim Lean Management geht es häufig um die gesamte Kette zum Einbau von vorhandenen Bauteilen. Auf dieser Abstraktionsebene geht es bei Scrum um den „Einbau“ von Anforderungen. Was aus meiner Erfahrung hierbei häufig übersehen wird ist, dass Anforderungen, die einer Definition of Ready genügen, erst „produziert“ werden müssen. Diese sehr kreative Vorgang ist nicht Teil von Scrum und der Aufwand wird häufig unterschätzt. Ohne klare Anforderungen ist aber keine gute Planung und schlussendlich auch kein Commitment möglich.
Hallo Kai, danke für deinen Kommentar. Ich kenne die Analogie bei Jeff Sutherland und halte sie für gefährlich. Sie suggeriert nämlich eine Trennung zwischen Spezifikation und Produktion im Sinne von „Einbau“. Im Idealfall will ich den Wertstrom zwischen Idee und Umsetzung nicht haben, sondern sehe das alles beim Entwicklerteam. Die Entwickler müssen die Stories verstehen und dazu hilft es ungemein, wenn sie selbst eng mit dem Kunden zusammen diese ausarbeiten. Ich will kein Ready-Team, das Stories für ein Done-Team vorbereitet.
Hallo Markus, schön gesagt. Im Mitelstand mit sehr begrenzter Personalkapazität wird ist das aber schwierig. Bei rein SW implemtierten Verfahren stimme ich voll und ganz zu. Im Anlagen- und Maschinenbau sieht das aber ein wenig anders aus. Klar gibt es auch Teams die interdisziplinär arbeiten, aber die Arbeit ist zeitlich sehr weit gestreckt. So findet das Systemsengineering meist im Vorprojekt noch ohne Auftrag statt und wenn dann nach 1 Jahr oder mehr der Auftrag kommt, dann gibt es beim Stahlbau eigentlich nur einen einzigen Sprint, der aber mehere Monate dauert. Inkremente funktionieren hier nur sehr begrenzt. Konstruktions- und SW-Ingenieure arbeiten sehr stark zeitversetzt, was den Teamgedanken nicht gerade stärkt. Während sich der Konstrukteur voll auf das Projekt C konzentriert, arbeitet der SW-Ingenieur noch am Projekt A und hat sich mit C nur am Rande befasst. Eine Produktionsanlge, noch dazu mit vielen verschiedenen Gewerklen ist sehr schwer in Inkrementen herzustellen. DA kommt dann auch einer bestimmten Ebene doch wieder das ungeliebte V‑Modell zum Einsatz. Aber auch dort ist Agilität gefragt, denn ich habe in meiner Jahrzehnte langen Praxis noch keine Anlage gesehen, die so gebaut wurde, wie zum Zeitpunkt des Angebotes vorgesehen.
Hallo Mark, sehe ich genauso. Die Zyklen sind in Hardware natürlich länger. Was zählt ist aber die Grundhaltung, dass ein interdisziplinäres Team in Zyklen mittels Feedback die richtige Lösung erarbeitet. Findet sich übrigens auch so im ersten Artikel in dem die Parallele von Scrum als Spielzug im Rugby zu Produktentwicklungsteams gezogen wurde: The New New Product Development Game Und die untersuchten Teams hatten alle einen Schwerpunkt in Hardware (immerhin war das 1986!):
FX-3500 medium-sized copier (introduced by Fuji-Xerox in 1978)
PC-10 personal-use copier (Canon, 1982)
City car with 1200 cc engine (Honda, 1981)
PC 8000 personal computer (NEC, 1979)
AE‑1 single-lens reflex camera (Canon, 1976)
Auto Boy, known as the Sure Shot in the United States, lens shutter camera, (Canon, 1979)
Guter Punkt. Wie kann Agile im „normalen“ Leben gelebt werden, abseits der separaten, elitären Neuprojekte in den „Coverstories“?