Agil vs. Wasserfall – Eine Sichtweise

In diversen Projekten und Beratungen werde ich immer wieder mit zwei sehr gegensätzlichen Ansätzen, Ansichten bzw. Philosophien konfrontiert: „Agil“ (im Englischen „agile“ genannt) und „Wasserfall“, oder irgendwas dazwischen. Häufig wird erwartet, dass beide Welten kurz in 30 – 60 Minuten erklärt und verglichen werden. Das ist ungefähr genauso, wie wenn einem Schiffskapitän kurz in einer halben Stunde erklärt wird, wie man ein Flugzeug fliegt und einem Piloten, wie man ein Schiff fährt. Natürlich gibt es Gemeinsamkeiten, dennoch sind beides völlig unterschiedliche Arten sich von A nach B zu bewegen.

Eine ähnliche Situation findet man vor, wenn Agile-Evangelisten auf Wasserfall-Evangelisten treffen. Finden Offenheit, Verständnis, Respekt und Einfühlungsvermögen für beidseitige Fragestellungen statt, ist es ein guter Start, um in eine konstruktive Diskussion zu gehen.

Beliebte Zielsetzungen im „Agil“en

Nachdem lange Zeit die Softwareentwicklung im Zeichen der traditionellen Vorgehensweisen und Methoden stand, wählen immer mehr Unternehmen mittlerweile agile Vorgehensweisen wie Scrum, Kanban, Lean, Extrem Programming oder ähnliches. Diese Umstellung erfolgt keineswegs grundlos, sondern in Anlehnung an unterschiedliche Zielsetzungen. Stellvertretend für zahlreiche Zielsetzungen, nenne ich hierfür die folgenden Drei:

  • Schnellere Umsetzung marktspezifischer Anforderungen
  • Verbesserung der Software-Qualität
  • Reduzierung von Kopfmonopolen und Wissensverteilung im Team

Bei allen drei Zielsetzungen stoßen die klassischen Vorgehensweisen in der Praxis häufig an ihre Grenzen. Mit den agilen Ansätzen sind sie hingegen sehr wohl zu erreichen. Doch wo liegen die Unterschiede und warum gibt es noch immer so viele Entscheider, die bei der Wahl der agilen Vorgehensweise zögern?

„Tradition“elle Vorgehensweisen und Ihre Leitplanken

Für viele konservativ eingestellte bzw. historisch gewachsene Unternehmen war es lange Zeit undenkbar, sich von klassischen Vorgehensweisen zu verabschieden. Die klar definierbaren Grundlagen und der hohe Bekanntheitsgrad trugen erheblich dazu bei. Das Vorgehen ist dabei immer ähnlich. So wird bei klassischen Vorgehensweisen, die auf der Genauigkeit der Planung basieren, unter anderem davon ausgegangen, dass sämtliche Anforderungen vor der Realisierung bekannt sind. Eine weitere Annahme ist, dass sich die diese Anforderungen während der gesamten Projektlaufzeit nicht oder zumindest kaum ändern. Um nach diesem Modell arbeiten zu können, müssen sämtliche Anforderungen bis ins Detail verstanden sein, mehr noch, sie müssen teilweise auch antizipiert werden. Vor allem wenn sich das Marktgeschehen während langer Projektlaufzeiten verändern wird. Und – auch die Technologien müssen bekannt sein, die für die Umsetzung der Anforderungen erforderlich sind. Sie müssen nicht nur wie vorgesehen funktionieren, sondern dürfen auch keinerlei Probleme verursachen. Treten Probleme auf, werden dadurch häufig teure „Mehraufwände“  verursacht, die sich häufig auf höhere Kosten, mehr Zeit und sinkende Qualität auswirken.

Der Unterschied zwischen “Agil” und “Wasserfall”

In der agilen Welt ist das anders. Dort werden Probleme flexibler gelöst. Nicht nur das: Es zeigen sich noch mehr deutliche Unterschiede, die in Management-Diskussionen häufig zu Sackgassen führen. Sackgassen deshalb, weil sich Agil und Wasserfall sehr konträr zueinander verhalten. Wie konträr, das möchte ich kurz anhand des Wasserfalls-Modells vs. Scrum skizzieren.

Während beim Wasserfall-Modell mindestens jede Woche ein Bericht gefordert wird, wird bei Scrum nach jedem Sprint die versprochenen Anforderungen im Review anhand eines lieferfähiges Software-Inkrement vorgestellt. Für die Planung der Wasserfall-Methode sind Personentage entscheidend. Dagegen wird bei Scrum häufig in „StoryPoints“ geplant. Scrum erwartet kurze, aber ebenso präzise UserStories gemäss den INVEST-Kriterien. Bei den klassischen Vorgehensweisen werden dagegen ausführliche Spezifikationen bevorzugt, häufig sogar detailliert in UML. Darüber hinaus steht im Wasserfall-Modell häufig die Weiterentwicklung still, wenn ein entscheidendes Kopfmonopol (= Experte = alleiniger Know-how Träger) nicht verfügbar ist, bspw. durch Krankheit, Urlaub oder Kündigung. Dagegen wird bei Scrum im Team agiert, sodass in diesen Fällen die Aufgaben an ein ganzes Team übergehen und umgesetzt werden. Auch bei neuen Mitarbeitern erweist sich Scrum als die bessere Lösung. Während im Wasserfall-Modell ein Mitarbeiter das neue Mitglied in ein Modul / Produkt / Service einarbeitet und die Zeit bis zum Erreichen der Produktivität schließlich bei sechs bis neun Monaten liegt, übernimmt die Einarbeitung bei Scrum das gesamte Team. Dadurch ist der neue Mitarbeiter schon während des ersten Sprints einsatzbereit und kann verschiedenste Aufgaben übernehmen.

Bei Scrum Teams handelt es sich im Idealfall um interdisziplinäre Teams. Demnach sind sie dazu in der Lage, sämtliche inhaltlichen Anforderungen eigenständig umzusetzen. Hierfür müssen sie von anderen Teams keinerlei Ressourcen ausleihen.

Wie wir sehen, gibt es zahlreiche Unterschiede, die wir noch seitenweise fortführen könnten. Jedoch wird eines deutlich, dass wir mit Scrum scheinbar einen äußerst flexiblen Ansatz in der Softwareentwicklung zur Hand haben, den es absolut lohnt, näher für die eigene Organisation zu betrachten. Er führt dazu, dass wir unsere Anforderungen schnell und flexibel umsetzen, gleichzeitig unsere Software-Qualität erhöhen und das bei gleichzeitiger Produktivitätssteigerung.

Fazit:
Mit dem gleichen Team kann ich mehr Anforderungen in der gleichen Zeit umsetzen, mit einer verbesserten Qualität ohne von nur einem einzigen Entwickler abhängig zu sein.

Nun, ich finde, das hört sich so gut an, dass es zumindest auch zu Diskussionen bei Ihnen führt. Finden Sie nicht auch?

Ich freue mich über Ihr Feedback.

Ihr Dr. Patrick Seifried
xingtwitterlinkedin

1 Antwort

  1. Skeptisch
    Ich stehe scrum sehr skeptisch gegenüber, es scheint mir auf zwei Grundprinzipien zu basieren: 1. (unzulässiger) Simplifizierung und 2. Kontrolle. Mir scheint es eher die Bedürfnisse von (einfach gestrikten) Projektmanagern im Blick zu haben, als die (Zusammen)Arbeit der eigentlichen Kreativkräfte. Es wird einfach nicht verstanden, dass Softwareentwicklung eine (zum Teil) hochspezialisierte und übrigens auch in den kreativsten Phasen sehr intime Ingenieurskunst ist. Auch wird einfach angenommen, dass wenn nur alle einzelnen Teile fertig sind, dann auch automatisch das gesamte System fertig ist. Scrum scheint keine Gesamtbetrachtung zu erlauben die jedoch z.B. beim Erfinden einer intelligenten Systemarchitektur unerlässlich ist. Dabei ist genau eine solche intelligente Systemarchitektur der Schlüssel zur Flexibilität, durch die auch später noch auf geänderte oder weitere Anforderungen entwicklungstechnisch reagiert werden kann. Ich glaube, dass scrum eine Art unglückseliger Versuch ist, sich vom Genie der Konzeptionierer und Entwickler unabhängig zu machen. Trotzdem sehe ich einen großen Bedarf, die Zusammenarbeit zwischen den Kreativkräften zu verbessern, aber das scheint mir eher eine Frage der geeigneten Tools und deren Verwendung zu sein.

Einen Kommentar schreiben