Auch Wasserfall ist agil. Die Schleifen in denen ein Produkt entsteht sind nur viel länger. Nach jeder Schleife trifft ein Ergebnis auf einen Kunden. Dann zeigt sich der Nutzen oder eben nicht und es kann der Kurs korrigiert werden. Bei Scrum alle zwei bis vier Wochen, bei klassisch Wasserfall eher nur zweimal im Jahr mit entsprechend höherem Aufwand und Risiko. Beides kann je nach Projekt und Kontext angemessen sein. Es kommt einfach darauf an, wie anpassungsfähig und reaktionsfähig ein Projekt sein will und muss.
Die Grundsatzfrage agil oder klassisch lässt sich lange und leidenschaftlich diskutieren. Genauso gut könnte man aber diskutieren, ob Wasser mit 0 oder 100 Grad Celsius besser ist. Es kommt darauf an. Will man Nudeln kochen braucht man kochendes Wasser, aber zum Blanchieren von grünen Bohnen Eiswasser. Espresso braucht 90 Grad, grüner Tee 70 Grad und zum Baden sollten es besser um die 38 Grad sein. Es kommt ganz auf den Zweck an.
Agil bedeutet wendig. Wendigkeit ist aber kein Selbstzweck, vielmehr bestimmt der Kontext des Projekts das notwendige Maß an Wendigkeit und Anpassungsfähigkeit. Je komplexer und unsicherer das Vorhaben, desto agiler sollte es angegangen werden. Nur gestehen sich die Unsicherheit nur die wenigsten ehrlich ein. Schon gar nicht wenn die Planungs- und Genehmigungsprozesse im Vorfeld des Projekts von Planbarkeit und Scheingenauigkeit geprägt sind.
Je planmäßiger die Menschen vorgehen, desto wirksamer trifft sie der Zufall.
Friedrich Dürrenmatt
Selbst wenn die Unsicherheit und Komplexität richtig eingeschätzt wird und ein agiles Vorgehen gewählt wird, bleibt die Anpassungsfähigkeit beschränkt durch Abhängigkeiten zu anderen Prozessen und Systemen. Selbst in kurzen Abständen potentiell auslieferbare Software hervorzubringen ist das Eine, Schnittstellenpartner und Datenquellen in halbjährlichen Releasezyklen sind nämlich das Andere. Durch Simulation der noch nicht vorhandenen Schnittstellen lässt sich auch das teilweise lösen, verschlechtert sich automatisch die Qualität der im Kontakt mit dem Kunden gewonnen Erkenntnisse.
Unterscheide ohne zu trennen, verbinde ohne zu egalisieren.
Herbert Pietschmann
Eine Diskussion über die beiden Pole agil und klassisch ist also nur insofern sinnvoll, als sie die Skala absteckt, Unterschiede und Variationsbreite herausarbeitet. Keinesfalls sollte diese Dichtotomie aber institutionalisiert werden wie es derzeit mit dem Hype der sogenannten bimodalen IT passiert und zu Recht von vielen kritisch gesehen wird.
Break down barriers between departments. People in research, design, sales, and production must work as a team.
W. Edwards Deming
Die entscheidende Frage lautet also nicht, agil oder klassisch, sondern vielmehr, wie agil das Projekt, Produkt oder „die IT“ insgesamt sein soll, darf oder muss. Neben der ehrlich eingeschätzten Unsicherheit spielt bei dieser Entscheidung das Vertrauen der Beteiligten zueinander eine ganz wesentliche Rolle. Wo die Kultur und Zusammenarbeit eher durch Angst, Absicherung und Schuldzuweisungen geprägt ist, wird aus einer negativen Rückmeldung der Kunden schnell Kritik. Anstatt gemeinsam und vertrauensvoll aus dem Irrtum zu lernen und die Richtung zu ändern, wird nach einem Schuldigen gesucht. Das führt zu noch mehr Misstrauen und Absicherung und damit zu noch längeren und insgesamt wenig lehrreichen Feedbackschleifen. Angst und Agilität passen eben nicht gut zusammen.
Success is not final, failure is not fatal: it is the courage to continue that counts.
Winston Chrurchill
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.
12 Kommentare
100% Zustimmung. Ein m.E. wichtiger zusätzlicher Aspekt: Die Labels alleine helfen nicht. Ich (Agilist, also 100° C ;) kenne zahlreiche Implementierungen von Agile, die nicht agil sind in Wesen und Kern. Und vieles, was sich Wasserfall nennt, ist nur hirnloses Planen ohne Blick auf die Realität. Wer die Werkzeuge anwendet ohne Verständnis u. Selbstkritik, der hat immer schlechte Karten, denke ich, egal, was er/sie macht.
Danke für Deine Zustimmung und Ergänzung, Sascha. Gerade um diese einfältige Benutzung der Labels geht es mir: Wir müssen erst verstehen, was das Projekt sinnvollerweise braucht und dann kompetent entscheiden, wie wir die Arbeit passend organisieren. Das ist natürlich um einiges schwieriger als Kochrezepte anzuwenden, darum retten sich ja so viele in möglichst griffige Labels. Und hirnloses Planen in Scheingenauigkeit macht so und so keinen Sinn.
Da waren sie wieder, meine Reizworte: Klassisch und Wasserfall in einem Satz. :-)
Projektmäßig bin ich sicher eher der „Warmduscher“ bei 42°C, also eher gemäßigt agil. Anders gesagt: Klassisches PM im Anlagenbau.
Soweit die Blödelei im Kontext.
Daß das Ausmaß an Agilität, bzw. besser das sorgfältige Abwägen zwischen Wendigkeit und Stetigkeit eine große Rolle im Projekt spielt, hast Du hier sehr treffend beschrieben.
In jedem Projekt sind (idealerweise, im Übrigen abweichend von fast allen Vorgaben der ISO9000) neue Regeln zu vereinbaren und regelmäßig zu überprüfen.
In den Projekten, die ich kenne, passiert das meist im Turnus von etwa 4 Wochen. Neben Design Reviews, in denen die Ergebnisse von Engineeringarbeiten besprochen und freigegeben werden, findet in diesem Takt auch meist ein detailliertes Projektstatusgespräch (eigtl ein Teamgespräch, bei dem alle Beteiligten die technischen und organisatorischen Details abstimmen) zwischen Kunde und Lieferant statt; je nach Bedarf wird dieser Takt aber auch angepaßt.
Aktuell findet das Gespräch wöchentlich statt, inklusive Durchsprache der Ergebnisse bzw. Produkte der letzten Woche.
In Inbetriebnahme- bzw. Go-Live-Phasen sicher nicht ungewöhnlich.
Übrigens bei den Chemieprojekten in der heißen Phase täglich: Nachbesprechung Vortag, Planung des aktuellen Tages, Vorschau auf die Woche. Längere Planung ergibt in dieser Phase keinen Sinn, da zuviel passiert und ‑Ihr ahnt es- Wendigkeit gefragt ist. (Von agil spricht da übrigens niemand. Der Begriff kam erst lange nach dieser Erkenntnis auf.)
Letztlich muß ich die Taktung aber auch an den Projektinhalt anpassen. Ich kann so agil arbeiten wollen wie ich mag – wenn das Projekt nun mal mehrere Wochen braucht, um überhaupt Reaktionen auf Steuerungsmaßnahmen zu zeitigen, laufe ich Gefahr, in Hektik zu verfallen, weil scheinbar lange nichts Interessantes passiert.
Da ist es besser, auch prozessual Ruhe zu bewahren und lieber in größeren Schritten zu denken und zu fühlen.
Die gewonnene Hirnkapazität kann man nutzen, um gemeinsam zu planen, bestehende Pläne anzupassen oder über den Haufen zu werfen, und sich auf anstehende Herausforderungen vorzubereiten.
Gerade in Infrastrukturprojekten sind die ausreichend bekannt, um für die nächsten paar Wochen vorauszudenken.
Agilismus und Wasserfall-Anbetung sind meiner Meinung nach die beiden Extreme, die jedes für sich völlig unrealistisch sind.
Die Wahrheit liegt dazwischen.
Und jedes Projekt hat seinen eigenen Agilitätsgrad, bei dem die Ergebnisse „al dente“ auf den Tisch kommen.
Den richtigen Punkt findet man aber nur durch Erfahrung und stetige Übung.
A propos Schuldzuweisung:
Egal ob Klassisch oder Agil – Ständig nach Schuldigen zu suchen, führt eine Organisation in den Abgrund, egal an welche Modelle sie glaubt.
Hi Marcus,
ein wenig Dogmatik hat doch noch niemand geschadet, oder? :-) Ich habe nicht nur ein mal gehört: Das Projekt läuft nicht –> Ihr macht jetzt agil.
Persönlich (und auch als PL, PO) finde ich die schnelle Reaktionsfähigkeit klasse, wenn sie sich bedarfsgerecht einsetzen lässt. Ich habe bisher erlebt, dass der Spaßfaktor (mit dem richtigen Team) immens ist. Und neben dem Spaß auch die Schaffung von Nutzen für den Kunden.
Es ist aber noch gar nicht lange her, wo ich zum agilen Vorgehen verdonnert wurde. In dem Unternehmen hat das an den etablierten Grundpfeilern gerüttelt. Als das Team das erste mal mit der Eigenverantwortung konfrontiert wurde – uiui – ich denke, ihr könnt´s euch vorstellen. Letztendlich haben wir eine agiles Projekt im Wasserfallmantel geführt.
Agil kann genauso Wasserfall sein, wie Wasserfall agil. Passen muss es! Das beschreibt dein Artikel sehr gut.
Grüße
Sven
Auch wenn der erste Satz sicher vor allem provozieren soll: Wasserfall ist nicht agil. Im Duden heißt es zu agil: „von großer Beweglichkeit zeugend; regsam und wendig“ Wasserfall hat nicht den Anspruch, wendig zu sein, sondern vorab alles planen zu können, um dann nur umsetzen zu müssen. Planung und Umsetzung und Testung und Livegang sind serielle Aufgaben, die getrennt voneinander erledigt werden können.
Grundsätzlich gehe ich bei dem Gedanken mit, dass die Rahmenbedingungen beeinflussen, wie sehr ich die Phasen von Planung und Umsetzung etc. trennen und serialisieren kann und davon abhängig kann und sollte das Vorgehen gewählt werden.
Die Frage lautet für mich also weder, agil oder klassisch, noch, wie agil das Projekt, Produkt oder „die IT“ insgesamt sein soll, darf oder muss, sondern wie genau ich vorher wissen kann, welche Lösung mir am Ende den größten Nutzen bringt, was am Ende gebraucht wird. Daraus entspringt auch eine mögliche benötigte Reaktionsfähigkeit.
Wenn Dinge nur einfach oder kompliziert sind, kann ich mit Wissen und Zeit vorab planen und dann umsetzen. Sind sie komplex und von vielen nicht verlässlich planbaren Faktoren (Menschen und deren Entscheidung z.B.) abhängig, eignen sich agile Vorgehensweisen, auch wenn die organisatorischen Bedingungen das nicht gut hergeben. Die Frage dann ist, wie man mit der Einschränkung umgehen kann.
Natürlich ist Wasserfall eher plangetrieben und genau deshalb eben weniger wendig / agil als agil ;-) Aber wir sind uns ja einig: es kommt auf das Vorhaben an. Und in der Tat sind viele Vorhaben ehrlich betrachtet komplex, werden aber als kompliziert eingeschätzt (weil machen wir immer so) und so getan als ob sie gut planbar wären.
Da sind wir uns einig. Brauche ich ein reaktionsstarkes Vorgehen, wähle ich eine agile Vorgehensweise, wenn nicht, dann nicht – und dann ist es ein plangetriebebes serielles Wasserfall-Vorgehen.
Um ehrlich zu sein finde ich die ganze Diskussion zu „aufgesetzt theoretisch“, weil sich m.E. der Begriff „agiles Vorgehen“ klar absetzt von „Wasserfall-Vorgehen“. Es gibt ein grundsätzliches Verständnis und da sind agiles Vorgehen und Wasserfall zwei gegenüberliegende „Enden“
Für das konkrete Vorgehen und den benötigten Grad an Wendigkeit muss der Kontext betrachtet werden. Wenn ich aber für jede Diskussion erst den Kontext klären und man sich auf eine Grundlage einigen muss, kommt man nicht voran. Gerade die Diskussion ob Wasser flüssig oder hart ist zeigt die Absurdität dieses Anspruchs. Zumal hart nicht das Gegenteil von flüssig ist und ich nicht behauptet habe, dass Wasser nicht auch hart sein kann. Wasser ist flüssig und nicht fest. Wasserfall ist träge und starr und eben nicht agil.
Btw. Wenn du von Projekten ausgehst, dann ist Wasserfall erst recht nicht agil, weil an einen abgeschlossenen Wasserfall Zyklus ein neuer Zyklus angehängt werden kann, das ist dann aber ein „neuer Wasserfall“ und nicht eine (träge) Beweglichkeit des alten Wasserfalls m.E.
Ein Containerschiff würde man auch nicht als agil bezeichnen, selbst wenn das eine im Vergleich zu einem anderen wendiger wäre. Und hier würde es noch eher passen als bei einem Wasserfall-Vorgehen.
Ja, die Diskussion drüben auf Twitter hat eine etwas philosophische (aber nicht weniger reizvolle) Richtung genommen, die ich jetzt nicht unbedingt hier vertiefen will. Und ja, einen Wasserfall an den nächsten anzuschließen macht den Wasserfall an sich noch nicht, sondern nur das Gesamtkonstrukt der mehreren Wasserfälle hintereinander (ein wenig jedenfalls).
Hallo Markus,
„Die entscheidende Frage lautet also nicht, agil oder klassisch, sondern vielmehr, wie agil das Projekt, Produkt oder „die IT“ insgesamt sein soll, darf oder muss.“ Ja, dieser Aussage stimme ich zu, möchte Sie aber noch ergänzen.
Barry Boehm von der University of Southern California und Richard Turner von der George Washington University schlagen in ihrem Artikel „Using Risk to Balance Agile and Plan-Driven Methods“ ein Modell vor, um zu testen wie sehr sich ein Unternehmen für eine agile Vorgehensweise eignet.
D.h. es stellt sich nicht nur die Frage wie agil darf es sein, sonder auch die Frage wie agil können wir überhaupt (falls gefordert).
Beste Grüße
Patrick
Danke für deine Ergänzung, lieber Patrick. Sehr interessanter Ansatz, den man hier nachlesen kann.
Vielen Dank für den sehr guten Beitrag.
M.E. ist der entscheidende Punkt, dass die Methode, das Führungs-/Steuerungsprinzip zur Aufgabe zum Kontext passen muss.
Das gilt für das gesamte Vorhaben (Projekt, Produkt), aber ggf. auch für die Module. (Hier helfen die „Wardley-Maps“)
Eine gute Orientierung liefert das Cynefin-Framework oder auch das Stacey-Portfolio mit der Unterscheidung zwischen komplex und „nur“ kompliziert.
Unter
www.process-and-project.net/spa
haben wir ein kleines Tool zur Verfügung gestellt, um die eigenen Aktivitäten einmal bzgl. Durchführungsform, Erfolg und Grad der Komplexität zu visualisieren.
(kostenfrei und ohne weitere Verpflichtungen o.ä. – Wir möchten einfach sehen, wie gut die Theorie mit der Praxis übereinstimmt.)
Vielen Dank. Der Kontext ist tatsächlich entscheidend. Darum mag ich die kontextfreie Diskussion um Methoden oder Best-Practices nicht. Ohne Beipackzettel mit Anwendungsgebieten, Nebenwirkungen und Wechselwirkungen macht das keinen Sinn.