Immer wieder wird die Idee der Agilität und ihrer Vorzüge für große Unternehmen in den Fokus der Ideen gerückt. Dabei werden immer wieder die erfolgreichen Projekte vorgestellt, die mittels Agilität so viel erreicht haben, und die gescheiterten Wasserfallprojekte auf ihre Schwächen reduziert gegenüber gestellt.
Aber keiner stellt sich die folgenden Fragen:
1. Warum wählen die Beteiligten, obwohl sie durch die Diskussion um die Agilität längst um Ihre Alternativen wissen müssten, immer wieder den „falschen“ Weg?
2. Decken agile Vorgehensweisen wirklich das ganze Projekt – also alle für ein Projekt erforderlichen Phasen und Aktivitäten ab?
Die erste Frage ist einfacher zu beantworten, als es zuerst scheint: die Entscheider für solche Projekte versuchen vor dem Start Informationen zu bekommen, die Ihnen die die Frage nach dem Nutzen und der Höhe des Nutzes beantworten. Keine agile Vorgehensweise kann einem die Kosten für die Umsetzung eines Vorhabens im Vorfeld liefern – höchstens eine unverbindliche und ungenaue Schätzung.
Aber selbst wenn das Projekt nicht vollständig in Frage gestellt wird, wird doch der Aufwand für die Umsetzung von Features von dem Aufwand abhängig gemacht, die diese erzeugen. Auch hierzu geben die agilen Vorgehensweisen nur dann Auskunft, wenn sich die Featurewünsche in der Größenordnung eines Sprints bewegen.
Je größer die Organisation, desto risikoaverser ist sie. Hierfür bieten die agilen Vorgehensweisen keine hinreichenden Lösungen.
Nicht falsch verstehen: Wasserfallmodelle helfen nur wenig mehr. Aber die Lösung, die diese Vorgehensweisen anbieten, sind nachvollziehbarer in dem Entscheidungsumfeld, in dem diese genutzt werden.
Aber selbst, wenn das alles keine Rolle spielt, was den wichtigsten Unterschied ausmacht, ist die Art und Weise, wie agile Projekte laufen. Die Entscheidung über die umzusetzenden Features macht das SCRUM Team und das anhand des Backlog. In größeren Organisationen kommen solche Entscheidungen nicht aus dem Team sondern vom Management – oft auch gegen den Wunsch des Teams.
Die zweite Frage ist komplexer. Was viele nicht verstehen am agilen Vorgehen ist, dass diese Erfahrungen im klassischen Projektmanagement voraussetzen. Um den Gewinn aus der nicht überbordenden Dokumentation und Erstarrung in Prozessen zu holen, braucht es Menschen, die die Erfahrung haben. Denn was die SCRUM Apologeten immer wieder vergessen: SCRUM ist die Königsklasse der Vorgehensweisen für Entwicklungsprojekte – ohne Erfahrungen in der klassischen Disziplin braucht es sehr viel Training, bis es funktioniert.
Die agilen Idealisten sind auch so tief in das eigene Vorgehen drin, dass sie einen wichtigen Punkt übersehen: die Vorgehensweisen helfen nicht in der Phase der Ideenfindung und der Analyse. Diese Phasen sind sehr wichtig für die Formung von Anforderungen und Ableitungen von Konzepten für die Architektur.
Immer dort, wo agile Vorgehensweisen erfolgreich eingesetzt werden, gibt es ein paar Eigenschaften, die nicht in immer anzutreffen sind:
- Die Projektbeteiligten arbeiten an einem Produkt das den Hauptgeschäftszweck für deren Firma darstellt.
- Die Projektbeteiligten arbeiten alle im und kommen aus dem IT Umfeld. Wir hören sehr wenig von agilen Projekten im Bauwesen.
- Die Projektbeteiligten sind direkt beteiligt und betroffen vom Ergebnis ihres Projektes.
Ein großer Teil der Projekte spielt sich aber in Konzernen ab, die IT nur als eine Querschnittsfunktion betrachten und für die Umsetzung auf Dritte setzen. Und wie durch ein Wunder sind das auch die Projekte, die immer wieder in die Schlagzeilen kommen.
Alle anderen Argumente zum Vergleich Wasserfall und agile Vorgehensweisen sind ausgetauscht, und brauchen nicht mehr wiederholt werden.