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.

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.)

Danke für deine Ergänzung, lieber Patrick. Sehr interessanter Ansatz, den man hier nachlesen kann.

„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

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).

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.

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.

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.

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

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.