Ich sage es Ihnen direkt: Die Frage „Agil oder Wasserfall?" ist die falsche Frage. Sie ist nicht nur falsch, sie ist gefährlich. Denn sie suggeriert, dass es eine richtige Antwort gibt. Eine Seite, die gewinnt. Einen Glaubenskrieg, den man führen muss.

Ich führe keine Glaubenskriege. Ich liefere Projekte.

Reinformen kommen in der Natur nicht vor

Es gibt Wasserfall. Es gibt Scrum. Es gibt Kanban, SAFe, Prince2 und was der Markt sonst noch an Frameworks ausspuckt. Jede dieser Methoden beschreibt wunderbar, wie der Methodenkoffer aussehen soll. Das Ideal. Die Reinform.

Aber schauen Sie sich die Natur an. Wo finden Sie dort Reinformen? Nirgends. Nehmen Sie den Wasserfall selbst: Ja, Wasser fällt. Aber gleichzeitig verdunsten riesige Mengen in der Gischt. Es fallen Erde, Holz, manchmal Fische. Ein Wasserfall ist kein reiner Prozess, er ist ein Chaos aus Kräften. Oder nehmen Sie den Wald: kein Baum wächst allein, jeder ist Pilznetzwerk, Insektenhotel und Wasserspeicher in einem. Oder das Wetter: kein Sturm ist nur Wind, er ist Druck, Feuchtigkeit, Temperatur, Geografie, alles gleichzeitig. In der Natur sind es immer Mischungen. Und so ist es auch im Projektmanagement. Oder besser: So sollte es sein.

Es geht doch nicht darum, ein Projekt „agil zu machen" oder ein Projekt „Wasserfall zu machen", nur weil ich glaube, dass diese Methode gerade en vogue ist. Die einzige Frage, die zählt, lautet:

Was muss ich tun, damit dieses Projekt erfolgreich wird?

Und es ist mir vollkommen egal, wie die Methode heißt, die mich dorthin bringt. Es ist mir egal, ob sie etabliert ist. Ob sie hip ist. Ob sie in irgendeinem Lehrbuch steht. Wenn sie funktioniert: wunderbar. Was will ich denn mehr?

Der erfahrene Projektmanager ist ein Methoden-Agnostiker. Er ist kein Sklave eines Frameworks. Er bedient sich an den Methoden wie an einem Buffet. Schamlos.

Das Reißverschlussmodell: Bekannt trifft Unbekannt

In meiner Erfahrung haben die meisten Projekte beides: Elemente, die bekannt sind, und Elemente, die völlig unbekannt sind. Und genau hier wird es interessant.

Für die bekannten Teile, wo ich weiß, was ich brauche, wo die Anforderungen klar sind, wo die Technik beherrscht wird, nehme ich Methoden, die näher am Wasserfall sind. Ich plane voraus, ich spezifiziere, ich baue sequenziell. Das funktioniert. Es ist effizient.

Aber für die unbekannten Teile? Da kann ich keinen Plan machen. Da kann ich keine Spezifikation schreiben. Weil ich schlicht nicht weiß, wie es geht. Oder ob es überhaupt geht.

Stellen Sie sich vor, Sie segeln im Nebel. Was tun Sie? Sie nehmen die Segel herunter und fahren unter Motor, halbe Kraft voraus. Sie tröten ins Nebelhorn, damit die anderen Sie hören. Sie sehen nur so weit, wie der Nebel es zulässt. Vielleicht hundert Meter. Vielleicht fünfzig. Also tasten Sie sich vor, Welle für Welle, und lauschen, ob die Brandung eines Ufers zu hören ist oder das Horn eines anderen Schiffes.

Genau das ist der agile Ansatz: Fahren auf Sicht. Sprint für Sprint. Und nach jeder Etappe dem Auftraggeber zeigen, wo wir stehen. „Sollen wir weitermachen? Oder drehen wir ab in sichere Gewässer?"

Das Reißverschlussmodell verbindet beide Welten. Die Zähne des Reißverschlusses, die agilen Sprints, greifen in das feste Band der klassischen Meilensteine. An definierten Synchronisationspunkten treffen sich beide Welten. Nicht als Kompromiss, sondern als bewusste Architektur.

Das Desaster: Festpreis für das Unbekannte

Ich habe ein konkretes Beispiel erlebt, das mir bis heute in den Knochen sitzt.

Eine Firma stellte Prototypen her. Nicht irgendwelche Prototypen, es gab dieses Produkt überhaupt noch nicht. Es war in keiner Hinsicht klar, wie dieser Prototyp gefertigt werden konnte, weil niemand wusste was er eigentlich alles können sollte. Keiner hatte eine Ahnung, ob die Technologie funktionieren würde.

Das Einzige, was in so einer Situation richtig ist: Agil arbeiten. Vier Wochen fahren. Schauen, was passiert. Lernen. Anpassen. Oder umdrehen.

Was hat die Firma stattdessen gemacht? Sie hat mit dem Kunden einen Festpreis vereinbart. Inklusive Deadline. Für etwas, von dem keiner wusste, ob es überhaupt möglich ist.

Das war tödlich.

Niemand wusste, wie es geht, es gab nur einen Betrag X und nur so-und-so-viel Zeit. Das gesamte unternehmerische Risiko lag bei der Firma. Die Kosten explodierten. Der Prototyp wurde nie fertig. Der Kunde war verloren. Das Geld war verbrannt.

Der Fisch stinkt vom Kopf. Der Fehler lag nicht beim Projektteam. Der Fehler lag im Vertragsabschluss, im Verkaufsprozess. Wer einen Festpreis für eine unbekannte Technologie unterschreibt, hat das Projekt die Toilette hinuntergespült, bevor es überhaupt begonnen hat. Kein Projektmanager der Welt kann diesen Geburtsfehler heilen.

Klauen Sie schamlos

Nehmen wir an, Sie bauen ein Haus. Klassischer Wasserfall: Plan, Anforderungen, Architektur, Bau, Abnahme. Klar.

Aber was spricht dagegen, während des Hausbau-Projekts jeden Morgen ein zehnminütiges Stand-up-Meeting zu machen? „Was passiert heute? Wer braucht was? Alles klar? Los geht's." Fertig.

Das Stand-up kommt aus dem Scrum. Ja, ist doch wurscht. Wenn es hilft, dass wir uns kurz verständigen, dann mache ich das. Nur weil eine Methode aus dem „anderen Lager" kommt, ist sie nicht verboten. Das ist pragmatisch. Das ist professionell.

Andersherum: Wenn Ihr Vorstand eine Jahres-Roadmap sehen will, zwingen Sie ihn nicht, das Product Backlog in JIRA zu lesen. Bauen Sie einen klassischen Meilensteinplan für die Stakeholder-Kommunikation, während das Team darunter in Sprints arbeitet.

Die Goldene Regel

Fragen Sie niemals: „Erlaubt die Methode das?"

Fragen Sie immer: „Hilft dieses Werkzeug uns, das Ziel effizienter zu erreichen?"

Wenn die Antwort Ja lautet: Machen Sie es.

Welches Werkzeug nimmt der Experte? Das Richtige. Je mehr Werkzeuge Sie beherrschen, desto besser können Sie situativ das angemessene wählen. Wirksame Führung schlägt methodische Reinheit.

Immer.

← Zurück zum Blog