Müsste man agiles Vorgehen auf ein Merkmal reduzieren, wäre das für meisten Menschen wohl das kontinuierliche Ausliefern von wertvollen Zwischenergebnissen. Freilich um dann im nächsten Atemzug zu erklären, warum das in ihrem jeweiligen Umfeld unmöglich oder jedenfalls sehr schwierig wäre und sie darum doch leider beim Wasserfallmodell bleiben müssen. Diese Ausrede Begründung klingt schlüssig solange man das kontinuierliche Ausliefern als condicio sine qua non betrachtet, was es aber nicht sein sollte.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Principles behind the Agile Manifesto
Frühzeitig und kontinuierlich dem Kunden einen Mehrwert zu liefern ist ganz ohne Frage die Kür. Am Ende ist der Wert beim Kunden der einzige Maßstab der wirklich zählt. Das hat zunächst aber nichts mit agil zu tun, weil allein das kontinuierliche Liefern von (angenommenen) Wert nicht verhindert in eine falsche Richtung zu laufen. Viel entscheidender ist der regelmäßige Abgleich des erwarteten mit dem tatsächlichen Kundennutzen und anschließender Kurskorrektur. Die kontinuierliche Auslieferung ist also nicht Selbstzweck, sondern in erster Linie Mittel um überhaupt die Position bestimmen zu können und damit wendig zu bleiben.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Principles behind the Agile Manifesto
Gewachsene IT-Landschaften, Organisationsstrukturen und Software-Architekturen erlauben es tatsächlich oft nicht, alle drei Wochen wertvolle Software an den Endkunden zu liefern. Zu stark sind die Abhängigkeiten und die damit verbundenen Aufwände zum Test. Trotzdem ist es fast immer möglich, in so kurzen Abständen Rückmeldungen von Endkunden zu Zwischenversionen einzuholen. Diese sind in der Regel sogar begeistert davon, dass sie am lebenden Produkt aktiv Einfluss nehmen können und nicht nur seelenlose Konzeptpapiere wälzen müssen.
Man kann sehr wohl agil vorgehen ohne alle drei Wochen an den Endkunden auszuliefern, solange man dafür sorgt, dass man alle drei Wochen Rückmeldung zu seinem „potentially shippable product“ erhält. Die echte Auslieferung kann dann zunächst wie gewohnt mehrfach im Jahr nach einem gemeinsamen Integrationstest zur Absicherung stattfinden. Zwar entsteht der Wert beim Kunden dann natürlich später im Zusammenspiel aber hoffentlich besser getestet.
For a new software system, the requirements will not be completely known until after the users have used it.
Watts S. Humphrey
Die eingeschränkten Möglichkeiten einer echten Auslieferung in kurzen Abständen darf nicht als Ausrede dienen, um nicht agil vorzugehen. Und wenn man sich entscheidet, agil vorzugehen, sollte man sich um die Fähigkeit in kurzen Abständen auszuliefern erst in zweiter Linie kümmern. Viel wichtiger wäre das Eingeständnis, dass es für komplexe Systeme den geradlinigen Weg wie ihn das Wasserfallmodell suggeriert nicht geben kann, sondern diese emergent entstehen und man daher in kurzen Abständen die eingeschlagene Richtung mit dem Endkunden zusammen überprüfen muss.
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.
6 Kommentare
Hallo Marcus,
ich sehe das „kontinuierliches Ausliefern“ nicht als Merkmal agilen Vorgehens, sondern vielmehr einen interessanten Aspekt agilen Denkens.
Allerdings hat manche diesbezügliche Formulierung schon etwas sehr Undifferenziertes an sich.
Kontinuierliches Ausliefern von nutzbaren Produkten ist nur eine mögliche Interpretation.
Ich würde es weiter fassen und vom Kontinuierlichen Ausliefern sinnträchtiger Ergebnisse sprechen.
Und das funktioniert auch im klassisch geprägten Umfeld hervorragend, aber genausogut im Tagesgeschäft oder ganz anderen Umfeldern:
Sei es ein laufender, sinnvoller Informationsfluß zum Kunden, welche Schritte abgeschlossen oder in Arbeit sind, oder was aus welchen Gründen länger dauert und wie der Kunde sich da mit einbringen kann;
Sei es ein kurzes Statusupdate in der Raucherecke;
Sei es ein Vorabzug einer Zeichnung, die der Kunde braucht, um einen anderen Lieferanten wieder in Schwung zu bringen.
Oder auch eine kurze technische oder vertragliche Information, die anderen Beteiligten hilft, ein Problem zu lösen.
Sobald man sich von dem sehr konkreten Begriff der „Produktlieferung“ löst und die „Auslieferung“ kreativer betrachtet, tun sich unglaubliche Möglichkeiten auf, den Kunden und andere Stakeholder im Loop zu halten und konstruktiv mit ihnen zusammenzuarbeiten.
Nach wie vor: Agile Methoden sind nicht immer geeignet;
Agile Denke hingegen, in Maßen eingesetzt, befreit den Geist und eröffnet Möglichkeiten.
Den klassischen Projekten wird immer vorgeworfen, nur an das vollständige Endprodukt zu denken; tatsächlich ist es aber so, daß jedes Endprodukt oder Projektergebnis auf dem Weg über tausende Zwischenprodukte entsteht, die um so werthaltiger sind, je bewußter man sie ausliefert.
Danke für Deinen Kommentar, Thilo! Das was Du als agiles Denken beschreibst, erinnert mich stark an die Bewegung working out loud. Transparenz und Kommunikation sind für mich Schlüsselfaktoren in jedem Projekt, egal in welcher Vorgehensweise. Agil heißt für mich aber schon kontinuierlich angenommenen Wert zu liefern und zu prüfen ob die Erwartung bestätigt wird. Es geht um nutzbare Zwischenprodukte und weniger um Teile des ganzen Produkts oder Planungsdokumente.
Ich würde Agilität mit „Verschwendung vermeiden“ gleichsetzen. Damit sind dann auch die Themen, die sich durch nicht vorhandene kontinuierliche Auslieferung ergeben abgedeckt.
Verschwendung vermeiden trifft tatsächlich den Kern der Dinge. Wenn man aber mit Agilität anfangen will, wäre mir anfangs die Fähigkeit, nützliche Zwischenschritte erarbeiten und irgendwie verproben zu können (mit allem was an Kultur, Architektur, Werkzeugen, etc. dazugehört) viel wichtiger als diese Zwischenschritte auch wirklich ausliefern zu können. Auch wenn das natürlich auch Verschwendung bedeutet, weil der echte Nutzen sich dann später einstellt.
Ist das eine Risikobetrachtung? Warum nicht schnellstmögliche Auslieferfähigkeit als Ziel, selbst wenn es am Anfang erst mal mächtig holpert oder sogar scheitert? Wenn man es als Experiment (ohne Konsequenzen!) betrachtet, ist das doch eine prima Vorgehensweise. Experimentieren, daraus lernen, neu ausrichten, nächstes Experiment.
Warum nicht. Diese Experimente und das lernen daraus setzen allerdings schon eine gewisse agile Grundhaltung voraus, die es noch nicht überall gibt. Vielmehr denkt man zu oft in endgültigen Lösungen und meint dann erst richtig agil sein zu können, wenn das kontinuierliche Ausliefern funktioniert, was ein bestenfalls ein Trugschluss und schlimmstenfalls eine Ausrede ist.