Warum die Agilen mit Wasserfällen nicht klarkommen (und umgekehrt) und warum sie miteinander Frieden schliessen sollten

«Agile or waterfall, that is the question». Abgegriffener geht’s nimmer, aber viel zu viele Diskussionen drehen sich nach wie vor um diesen Spruch. Allein, die blosse Polarisierung bringt uns nicht wirklich weiter. Was aber, wenn wir einen echten Lernprozess durchliefen und zu zwei banalen Erkenntnissen kämen: 1. Es kommt drauf an und 2. Zusammen ginge es besser.

Monty Python’s[1] C und P

Kennen Sie Monty Pythons epochales Werk «The Meaning of Life»? Die berühmte Szene in einer grauen, düsteren Strasse in Bradford, Yorkshire? Auf der einen Seite der Strasse wohnen die C (die Coolen), ein buntes, agiles und furchtbar fruchtbares Volk, das sich vehement und singend gegen die Verschwendung wehrt und auf der anderen Seite der Strasse leben die P (die Planer)[2]: langweilige, graue Figuren, mehr oder weniger unfruchtbar, und ohnehin nichts verschwendend.

Genau dieses Bild befällt mich immer auf subversive Weise, wenn wieder irgendwo die Diskussion um die Vorzüge und Nachteile von agilen gegenüber traditionellen Projektmanagement-Methoden losbricht.

Während allerdings die Polarisierung der C und P bei Monty witzig und humorvoll (zugegeben als tiefschwarzer britischer Humor) daherkommt, ist dieselbe Polarisierung von Agilen und Wasserfällen dumpf, humorlos und (sorry Monty, diesmal gehört das Wort mir) absurd.

Entsorgung von Schwachsinn tut not (I): Das Wasserfallmodell ist nicht

Genauso wie die amerikanische Regierung 2003 der ganzen Welt weismachte, dass Saddam Hussein über Massenvernichtungsmittel verfügt haben soll, bis sie den Krieg herbeigeschwatzt hatten, reden uns die ganz Agilen schon viel länger ein, dass die zu verdammende Methode die ‘Wasserfallmethode’ sei. Sie haben bis heute nicht verstanden, dass der erste, der die angebliche ‘Wasserfallmethode’ beschrieb[3], a) das Wort ‘Wasserfall’ in seinem Papier nie erwähnte, b) festhielt, dass er die Umsetzung eines solchen Verfahrens als ‘… risky and invites failure’ beurteilte und c) folglich nicht lineare, sondern iterative Methoden propagierte. An guten Feindbildern muss man nur lange genug festhalten, dann werden sie wahr und der Krieg kann beginnen. Sprechen wir deshalb besser von traditionellen oder iterativen Methoden, statt von Wasserfall und ähnlichem Schwachsinn.

Entsorgung von Schwachsinn tut not (II): Wahr und falsch sind auch nicht

Jeff Sutherland, der wohl bekannteste Missionar von SCRUM (und ehemaliger Kampfpilot in Vietnam, was vielleicht das Eine oder das Andere erklärt), der populärsten agilen Methode, lässt sich in seinem Buch ‘SCRUM: The Art of Doing Twice the Work in Half the Time’ (2014) über Gantt-Charts, den Balkendiagrammen also, mit welchen ‘Wasserfallprojekte’ gerne beschrieben werden, aus: «The only problem with them is that they are always, always wrong». Zwei Seiten später sagt Sutherland über ‘seine’ Methode: «Now it is the only way proven to help projects like these…”. Sutherland hat recht, nur geht der Dreh andersrum! Mit einer Projektmanagementmethode kann man Modelle von Vorhaben bilden und dass Modelle allesamt falsch sind, hat der berühmte George Box schon 1978 festgehalten: «All models are wrong, but some are useful».

Und umgekehrt wäre ja überhaupt nie ein Projekt gelungen, bevor SCRUM erfunden war.

Also lassen wir die rhetorischen Kraftmeiereien (Draufhauen statt Denken) und wenden uns der Lösung des Problems zu. Denn längst nicht alles, was die Menschen mit traditionellen Methoden hergestellt haben und immer noch herstellen, war/ist ein Desaster und längst nicht alles, was die Menschen mit agilen Methoden bauen, ist das Himmelreich.

Es wird schon so sein, dass die Traditionellen allzu lange ihre Methoden vom Hundertsten ins Tausendste verfeinert, erweitert und ergänzt haben und dabei übersehen oder verschlafen haben, dass sich der Fokus längst von Projekt per se hin zum Kunden und zum Produkt bewegt hat. Bis 2001 mit dem Agilen Manifest[4] eine pointierte, aber wohldurchdachte Richtungskorrektur eingeleitet wurde. Und es wird wohl auch so sein, dass vor allem die hard-core Agilen die konservativeren Teile (die Werte auf der ‘rechten Seite’) des Agilen Manifests gleich am Stück über Bord warfen und fortan jede Schraube mit dem Hammer einzuschlagen gedachten. Das unablässige und streng getaktete Streben nach dem Minimum (sic!) Viable Product produziert allerdings meist später mit viel Geld zu behebende Technische Schulden, obwohl der vorerwähnte Scrum-Papst Jeff Sutherland in seinem Buch dem Thema ‘Waste is a crime’ ein ganzes Kapitel widmet und darin in einem Abschnitt festhält ‘Do it right the first time’! Was sich in der einen Situation als durchaus logisch darstellt, erweist sich einen Moment später als Widerspruch.

Und zweifellos hat es in der Vergangenheit häufig zu lange gedauert, bis man einem sich abzeichnenden Misserfolg den Stecker gezogen hat, aber genauso fraglich ist es, wann das ‘Fail fast, fail often, fail forward’-Mantra nur eine dummdreiste Ausrede ist oder ein Vorhaben tatsächlich vorwärtsbringt.

Es trifft einmal mehr zu, was fast immer zutrifft: Es kommt drauf an!

Nicht einmal bei Socken gilt «One size fits all», wie kann man dann bei Projektmethoden solche oder ähnliche Erwartungen haben?  Es kommt eben drauf an, welches Problem es zu lösen gilt und welches die dafür am besten geeignete Methode ist. Und wir tun gut daran, von den verschiedenen Methoden zu lernen, sie in geschickter und nutzbringender Weise zu kombinieren und zu nutzen.

Einigkeit herrscht mittlerweile darüber, dass prinzipiengeleitete Kollaboration besser funktioniert als wenn starre Regelwerke Teams in Ketten legen. Das führt uns direkt zu einigen Fundamentalprinzipien des Projektmanagements:

1. Tailoring
   So nannte man früher einmal das Prinzip des Anpassens der Prozesse und Werkzeuge an das zu lösende Problem. Tailoring ist aktueller denn je! Immer. Überall. Bei den Traditionellen und bei den Agilen.
2. Planung (die Lieblingszielscheibe der militant Agilen…)
   Egal wie sehr wir mit einem Projekt unbekanntes Terrain betreten, wie wenig wir und unser Kunde zu Beginn eines Projekts wissen, wie unvollständig der Product Backlog ist und wie sehr wir uns auf Kundenwünsche einlassen wollen, wir kommen um ein Minimum an Planung nicht herum. Lars Vollmer hat das treffend beschrieben; «… Aber andererseits gibt es dennoch keinen Grund, Planung gering zu schätzen. Es ist nämlich so: Es gibt in jeder Zukunft einen bekannten und einen unbekannten Teil. Für den bekannten können Sie planen, für den unbekannten müssen Sie sich gut vorbereiten. Die Klugheit besteht darin, das eine vom anderen zu unterscheiden…»[5]Das Problem, dass sich Traditionelle oft der Überplanung hingeben und Agile notorisch unterplanen, ist bekannt und lässt sich lösen: durch Austausch und Zusammenarbeit der beiden Lager.
3. Schätzungen
   Wie wir’s auch drehen, wir kommen um angemessene Schätzungen (Aufwände, Kosten, Zeitdauern) nicht herum, wir brauchen Schätzungen und kontinuierlich verbesserte Schätzungen, um eine halbwegs vertrauenswürdige Planung hinzukriegen. Ausschliesslich relative Schätzungen (à la Planning Poker) helfen nur bedingt, spätestens wenn der Kunde eine ‘Hausnummer’ will, um zu wissen, wie tief und wann er in seine Tasche greifen muss, sind auch absolute Grössenordnungen gefragt.
4. Zusammenarbeit
   Zugegeben, vor allem die Traditionellen haben sich zu oft und zu sehr nur auf Kosten, Termine und Umfang des Projekts konzentriert und sich zu wenig um den Kunden, sein Bedürfnis und das dereinstige Produkt gekümmert. Obwohl alle haargenau wissen, dass die intensive Zusammenarbeit, der direkte und dauernde Austausch und ebenso die dauernden Rückmeldungen (bidirektional!) für den Projekterfolg und für die daraus entstehenden Produkte und Werte massgebliche Schlüsselfaktoren sind.
5. Projekt vs Produkt
   Noch heute ist bei vielen Traditionellen fest verdrahtet, dass der Projekterfolg im Vordergrund steht und alles, was danach folgt (Produkt, dessen Akzeptanz, Betriebs- und Wartungskosten etc.), von sekundärer Bedeutung ist. Diese Haltung ist in mehrerlei Hinsicht schlicht falsch. Was nützt mir ein hervorragend abgewickeltes Projekt, wenn der Markt das entstandene Produkt nicht zur Kenntnis nimmt, nicht akzeptiert, nicht kauft oder dieses nicht erfolgreich betrieben werden kann? Ford Edsel (1957) und die Suchmaschine Alta Vista (1995) sind nur zwei bekannte Beispiele für solche Dramen. Es braucht mehr für den Erfolg, viel mehr. Das Verständnis für eine entsprechend ausgebaute Zielhierarchie ist vorhanden, sie gilt für die Agilen wie für die Traditionellen.
6. Time-to-market
   Keine Frage, der Druck und die Geschwindigkeiten, rasch Innovationen umzusetzen und auf den Markt zu bringen, hat in den letzten Jahren massiv zugenommen. Oft sind wenige Tage bis Wochen Vorsprung auf die liebe Konkurrenz matchentscheidend. Da kann es durchaus sein, dass agile Verfahren helfen, den Wettlauf mit der Zeit zu gewinnen. Aber: nicht immer ist Time-to-market das entscheidende oder gar das einzige Erfolgskriterium. Gerade wenn man besser als die etablierte Konkurrenz (neudeutsch: disruptieren) sein will, gelten ganz andere Massstäbe und Faktoren wie bessere Qualität, besseres Kundenerlebnis, besseres Marketing, höhere Profitabilität etc. Hätte sich die Handelsplattform Siroop mehr Zeit genommen, einen besseren Namen zu suchen, bessere Werbung zu machen, besseres Marketing zu betreiben, hätte sie sich vielleicht gegen die etablierten Plattformen durchsetzen können, aber offensichtlich hat man sich die Zeit für ein besseres Produkt nicht genommen. Interessant wird auch sein, wie der Fall Tesla ausgehen wird. Es ist zwar cool, wenn man als Europäer seinen Tesla irgendwo in den USA per Handy öffnen kann, aber noch cooler wäre es, wenn das Auto auch wie ein Auto nach den Regeln des Gewerbes gebaut wäre.
7. Kleine Projekte
   Verschiedene Untersuchungen haben gezeigt, dass die sequentielle (wasserfall-mässige?!) Abwicklung von kleineren Projekten gegenüber der monolithischen Durchführung von Megaprojekten massive Vorteile aufweist, dies sowohl bei der Projektentwicklung, bei der Stabilität des Vorhabens, bei Wartung und Unterstützung des späteren Produkts. In diesem Punkt sind die Agilen klar im Vorteil, die kleinteilige Entwicklung ist ihr Standard. Umgekehrt fragt man sich natürlich, weshalb trotz deutlich geringeren Erfolgschancen, immer wieder Megaprojekte bis hin zum Typus Mission Impossible in Auftrag gegeben werden. Das Prinzip der kleinen Projekte gilt genauso für Agile wie für Traditionelle.
8. Das Team
   Das Zitat «Culture eats strategy for breakfast» wird Peter Drucker zugeschrieben. Unabhängig davon, ob Drucker dies tatsächlich gesagt hat, ist nachvollziehbar, dass gutes Teamwork enorm weit trägt und umgekehrt ein dysfunktionales Team ein Projekt rasch und zuverlässig an die Wand fahren kann. Damit sind wir beim allerwichtigsten Faktor für den Projekterfolg und wie schon zuvor illustriert, gelten auch die Prinzipien guter Teams sowohl für die Agilen wie für die Traditionellen.Wenn es nämlich gelingt, Teams zu schweissen, die verstehen, worum es im Kern bei einem Projekt geht, ohne dass man den einzelnen Teammitgliedern sagen muss, was sie zu tun haben, die sich also selber organisieren, die voneinander und füreinander lernen, die sich an gemeinsam festgelegte Prinzipien halten, dann ist die allerwichtigste Bedingung für den Projekterfolg erfüllt.

Also zurück zum Tailoring, das in diesem Fall auch gerne Cherry-Picking genannt werden darf

Lasst uns doch agile und traditionelle Techniken und Methoden gezielt immer dort einsetzen, wo sie uns am meisten nützen und helfen. In der Tendenz sind das agile Methoden, wenn wir die unbekannten Teile der Zukunft erschliessen müssen und traditionelle Techniken, wenn wir bereits mehr über die Zukunft wissen.

Und zurück zu Monty

Zum Schluss der Strassenszene bewegen sich die C und die P zusammen singend über die triste Bradforder Strasse in eine bessere Zukunft.

Allerdings trennen sich kurz danach unsere Wege von jenen von Monty Python. Während es bei «The Meaning of Life» zunehmend absurder zu und her geht, begeben wir uns friedlich und gemeinsam auf die Strasse des «Meaningful Life Cycle».

[1] Visionär wie die Truppe war, hat sie sich bereits 1969 mit Python befasst, also gut 20 Jahre bevor man das Potential von Python für Datenauswertungen erkannt hat…

[2] Eigentlich heissen sie anders, aber ich will mich jetzt nicht auch noch aufs religiöse und/oder politische Glatteis begeben.

[3] Winston P. Royce; Managing the Development of Large Software Systems; IEEE Wescon, 1970

[4]    Manifesto for Agile Software Development:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

[5] Lars Vollmer; Wie sich Menschen organisieren, wenn ihnen keiner sagt, was sie tun sollen; Gorus Certified Publications; 2. Auflage, 2018