Agil und Wasserfall – Klar zu trennen oder doch kombinierbar?
Bei der Frage, wie man am besten bei dem managen und ausarbeiten eines Projektes vorgeht, hört man zumeist von zwei Entwicklungsmodellen, die auf den ersten Blick wohl unterschiedlicher nicht sein könnten. Auf der einen Seite das klassische Wasserfallmodell, das als strukturiert, übersichtlich und vorhersehbar gepriesen wird, und auf der anderen Seite das Agile Modell, welches durch seinen schnellen, iterativen und flexiblen Ansatz hervorsticht. Doch sind es wirklich zwei Vorgehensweisen, die sich schlicht ausschließen, oder handelt es sich nicht eher um zwei etablierte Modelle, die nicht nur voneinander profitieren sondern auch kombiniert werden können?
Fließend ans Ziel
Das sogenannte Wasserfallmodell ist der traditionelle Projektmanagementansatz, welcher aufgrund seiner linearen Vorgehensweise dazu genutzt wurde, um Struktur und Disziplin in die oftmals chaotische Softwareentwicklung zu bringen. Zurückgeführt wird das Modell auf den Computerwissenschaftler Dr. Winston W. Royce, der 1970 in seiner Publikation Managing the Development of Large Software Systems darauf verwies, dass das gängige 2-Stufen-Entwicklungskonzept aus Analyse und Coding vor allem bei größeren Projekten nicht zielführend ist.
Royce warb dafür, große Projekte lieber in mehrere Stufen zu unterteilen, die aufeinander aufbauen und in einer festgelegten Reihenfolge verlaufen. Er selbst verwendete in seiner Publikation in keinem Satz das Wort Wasserfall, jedoch etablierte sich die Bezeichnung recht schnell, da die linear abfallende Stufenabfolge - die in ihrer Grundform kein Weg zurück kennt - schlichtweg an fallendes Wasser erinnert.
Sein Modell könnte man auch als ‚think first, code later’ beschreiben, da bevor die Analyse überhaupt startet zunächst alle notwendigen Anforderungen geklärt sein sollten und dem Coding eine Designphase vorhergeht. Dieses vorausschauende Planen kombiniert mit den ineinandergreifenden Arbeitsschritten sollte dafür sorgen, dass Projekte einfacher betriebsbereit, pünktlich und innerhalb der Kosten vollendet werden können.
Klar definierte Struktur und Phasen
Heutzutage besteht der sequentielle Prozess der Wasserfallmethodik je nach digitalem Projekt aus 5 bis 7 typischen Phasen, die sich beispielhaft wie folgt anordnen:
- Initialisierung: Festlegen der Projektziele und aller geschäftsrelevanten Aspekte wie Kosten, Ressourcen und Verfügbarkeit.
- Analyse: Ausarbeiten der Nutzungsanforderungen und Erstellen eines Grobkozepts über die Funktionen und Eigenschaften des Produktes.
- Konzeption: Die Anforderungen werden spezifiziert, sodass eine klare to-do-Liste für Design und Programmierung erstellt werden kann.
- Design: Konkrete Lösungskonzepte für das visuelle als auch technische Design. (UI, System- sowie Informationsarchitektur)
- Programmierung: Realisierung der in der Design-Phase konzipierten Architektur. Die Komponenten werden seperat entwickelt, integriert und Modultests unterzogen.
- Testen: Nach der abgeschlossenen Implementierunge wird das System überprüft und auftretende Fehler behoben.
- Betrieb: Das fertige Produkt wird ausgeliefert. Je nach Bedarf können hierauf weitere Tests, Wartungen oder Optimierungen folgen.
Die optimale Umsetzung des Wasserfallmodells sieht vor, dass jede Phase konsequent abgearbeitet und als Meilenstein abgeschlossen wird. Dies bedeutet, dass eine neue Phase nur dann begonnen werden kann, wenn die vorherige Phase mit einem klaren Ergebnis für beendet erklärt wurde. Damit in diesem Kontext die Nutzer nicht auf der Strecke bleiben, begleitet seit Anfang der 90er der Prozess des Human-Centered-Design (HCD) die Entwicklung von Beginn an. Hier legen die Entwicklerteams einen großen Wert auf Usability und greifen hauptsächlich auf Standards und Styleguides zurück, die sich in der Mensch-Maschine-Interaktion (HCI) bewährt haben.
Das Wasserfallmodell in Kombination mit HCD hilft durch die übersichtliche Organisationsstruktur mit klar definierten Phasen und Leistungsparametern dem Projektteam und –manager Unklarheiten früh zu beseitigen und den Fokus auf das aktuelle Arbeitsfeld zu legen. Außerdem liegt der Schwerpunkt der Methode auf der gesamten Projektdokumentation, da jede Phase ausführlich erfasst wird und mit einem Meilenstein endet.
Dies stellt aber auch gleichzeitig einen der Nachteile des Modells dar. Die Dokumentation hat einen solch übergreifende Stellenwert, dass sie u.U. wichtiger als das eigentliche System genommen wird. Die starren, linearen Prozesse erforden zudem eine hohe Vorhersehbarkeit des Projektverlaufs. Das Ergebnis und somit auch der Return on Investment sind erst nach Abschluss des Gesamtprojekts wirklich sichtbar. Wenn also der notwendige wie zeitfressende Konzeptions- und Anforderungsanalyse-Aufwand fehlerbehaftet ist, verläuft die Planungen in eine falsche Richtung und die Methode versagt.
Agiles Arbeiten dank hoher Flexibilität
Um den straffen und ohne Rückkopplungen versehenen Ablauf des Wasserfallmodells zu durchbrechen, wurden in den vergangenen Jahren eine Vierlzahl an agilen Methoden entwickelt, die sich durch eine hohe Flexibilität auszeichnen. Allen gemein sind 4 wesentliche Werte, die 2001 von einer Reihe namhafter Entwickler während des sogenannten Snowbird-Meeting im Agile Manifesto formuliert wurden:
- Individuen/Interaktionen wichtiger als Prozesse/Werkzeuge
- Funktionierende Software wichtiger als umfassender Dokumentation
- Kunden-Zusammenarbeit wichtiger als Verhandlungsführung
- Reagieren auf Veränderung wichtiger als das Befolgen eines Plans
In diesen Werten sieht man bereits einige Unterschiede zum klassischen Modell. Statt einem eher bürokratisch daherkommenden Prozess zu folgen, bricht man das Projekt auf und konzentriert sich auf schnelle Iteration. Die Themenbereiche werden in kurzen Zyklen - besser bekannt als Sprints - bearbeitet, getestet und abgeschlossen. Dies erlaubt den Entwicklern auf jegliche Änderung sowie auf Kundenfeedback schnell zu reagieren.
Success today requires the agility and drive to constantly rethink, reinvigorate, react, reinvent.
Die Anforderungen und Aufgaben ziehen die selbstorganisierten Teams aus den im Vorfeld erarbeiteten User Stories, welche sich als Anwendungsfälle an den Nutzerbedürfnissen orientieren. Dank der Sprints, die über wenige Tage bis hin zu mehreren Wochen dauern, können Ideen schnell überprüft und verwirklicht werden, da am Ende jedes Arbeitszyklus eine fertige Produktfunktion bzw. ein Prototyp steht, der von den Nutzern getestet werden kann. Die so in jedem Durchgang ermittelten Ergebnisse geben weitere Aufschlüsse über “Das, was funktioniert” und “Das, was (noch) nicht funktioniert”, sodass sie in den nächsten Sprint eingebaut werden können.
Lean UX: Agil und Nutzerorientiert
Wenn es aktuell um Service- und Produktentwicklung im Angesicht der Nutzer geht, sprechen wir häufig von Lean UX. Diese Vorgehensweise verbindet den agilen Entwicklungsansatz mit der Design Thinking-Methode, damit schnell und effizient neue innovative Lösungen für komplexe Probleme gefunden und direkt mit den Nutzern getestet werden können.
Hier bringen interdisziplinäre Teams ihre Kompetenzen und verschiedenen Sichtweisen ein, um gemeinsam die beste Idee für die Produktentwicklung zu finden. Die Idee muss dabei einen echten Mehrwert für die Nutzer schaffen, d. h. wenn sie sich in ersten Tests als nicht tragfähig erweist, wird sie direkt entsorgt und ein neuer Anlauf genommen. Fehler sind dabei nicht nur erlaubt sondern auch notwendig, da man daraus ebenfalls wichtige Erfahrungen zieht, die einen auf die richtige Fährte locken. Falls das Team also auf Grundlage der Nutzerdaten Annahmen trifft, die ein gewisses Risiko mit sich bringen falsch zu sein, können frühzeitig Nutzer hinzugezogen werden, welche die Idee challengen können und somit bei der Validierung der Annahmen helfen.
Gleichzeitig wird im Lean UX auch der Lean Startup Gedanke verfolgt. Hier steht am Ende des Zyklus ein Minimal Viable Product (MVP) – Also das kleinste lebens- bzw. funktionsfähige Produkt, welches dank der nötigsten Kerneigenschaften bereits brauchbar für die Nutzer ist. So kann nach jedem Sprint evaluiert werden, ob die Basics überhaupt funktionieren und, wenn ja, wie man sie direkt im Folgesprint weiter ausbauen und verbessern kann.
Kein Projekt gleicht dem anderen
Beide Entwicklungsmodelle haben ihre Vor- und Nachteile. Während das Wasserfallmodell mit seinem sequentiellen Ansatz einfach zu verwalten ist und sich vor allem für Projekte mit genau definierten Anforderungen, bei denen keine Änderungen zu erwarten sind, eignet, besticht die Agile-Methode durch eine hohe Flexibilität, welche Änderungen in jeder Phase erlaubt. Die Projektanforderungen sind somit nicht in Stein gemeißelt und die kürzeren Arbeitszyklen erlauben eine schnellere Fehlererkennung sowie eine frühe Einbindung des Endnutzers als begleitende Konstante.
Klar ist, dass jegliches Projekt mit seinen speziellen Anforderungen, Eigenheiten und Herausforderungen aufwartet. Deshalb muss je nach Unternehmen und Projekt individuell entschieden werden, welches Vorgehensmodell sich am besten für die Umsetzung eignet oder ob man eine Art Kombination aus beiden ausarbeitet. Royce selbst hat schließlich bereits in seiner Publikation mehrere optionale Phasen und Iterationen in das Modell eingebaut, die getestet werden sollten. Schlussendlich geht es einzig und allein darum, die Rahmenbedingungen zu ermöglichen, um klare Arbeitsschritte vorzugeben und das Projekt schlichweg planbar zu machen, ohne das Team unnötig in ein zu festgezogenes Korsett zu zwängen.