Agile vs Wasserfall? - Fractional CTO

In einer Welt, in der Agilität zur Norm für das Management von Softwareprojekten geworden ist, scheint es unvorstellbar, sich zu fragen, ob Wasserfall und traditionelles Projektmanagement eine Option sind. Dennoch fragte mich neulich ein Manager, ob für Implementierungsprojekte und die Anpassung eines Produkts bei Kunden traditionelles Projektmanagement interessanter sein könnte als die Verwendung einer agilen Methodik. Und die Wahrheit ist, dass es mir wie eine gute Gelegenheit erschien, darüber zu schreiben, was Agile im Vergleich zu traditionelleren Modellen bietet, gerichtet an ein Management-Publikum, das nicht so vertraut mit Agilität ist.

Ich möchte also das Warum von Agile (wenn auch nicht sehr tiefgehend) erneut betrachten und einige Fragen stellen, die sich Führungskräfte stellen können, um zu verstehen, ob Agile eine geeignete Philosophie für ihre Kontexte ist.

Das Erste, was man verstehen muss, ist, dass die Agile-Bewegung als Reaktion auf die Probleme mit den traditionellen Projektmanagement-Praktiken der 1990er Jahre entstanden ist, wie zum Beispiel Wasserfall. Schauen wir uns an, was Agile zu lösen versucht:

Beim Wasserfall-Modell fand die Übergabe an den Kunden normalerweise am Ende des Projekts statt und manchmal an einigen vordefinierten Meilensteinen während der Projektplanungsphase. Das Problem war, dass sie feststellten, dass diese Arbeitsweise oft bedeutete, dass das Entwickelte nicht den tatsächlichen Bedürfnissen des Kunden entsprach oder dass sich diese Bedürfnisse während der Entwicklung geändert hatten. Dies führte dazu, dass ganze Projekte nach Jahren der Entwicklung verworfen wurden. Um dieses Problem zu lösen, fördert Agile häufige iterative Lieferungen, die es ermöglichen:
- Dem Kunden frühzeitig Mehrwert zu liefern
- Den Kunden während der Entwicklung einzubeziehen, indem Feedback eingeholt wird, um den Kurs anzupassen, und sicherzustellen:
  - 1. dass die Lösung den Zwecken des Kunden dient. Als wichtige Anmerkung: Agile konzentriert sich auf die Ergebnisse für den Kunden und betrachtet die gelieferte Software als Mittel, um dem Kunden bei der Erreichung dieser Ergebnisse zu helfen;
  - 1. dass das Entwicklungsteam keine Zeit mit Dingen verschwendet, die dem Kunden nicht dienen;
  - 1. dass nicht zu viel Zeit zwischen der Entwicklung und der Validierung durch den Kunden vergeht, da nachgewiesen wurde, dass die Änderung umso kostspieliger wird, je länger diese Zeit ist (intuitiv lässt sich verstehen, dass es viel einfacher ist, ein gestern erstelltes Dokument zu ändern als eines, das vor einem Jahr erstellt wurde).

Wie Sie erkennen, ob Agile für Ihr Projekt geeignet ist:

Sind Projekte von Anfang an perfekt spezifiziert oder fehlt es ihnen oft an Definition?
Gibt es für meine Kunden einen Vorteil, wenn ich so früh wie möglich und dann inkrementell Mehrwert liefere? Oder profitieren meine Kunden erst, wenn alle Zusagen geliefert sind?
Gibt es eine Lernkurve für meine Kunden bei der Nutzung meiner Software, die ich abmildern kann, wenn ich die Software früher liefere?
Hat in der Vergangenheit, als mein Kunde die Software erhielt, diese immer perfekt seinen Bedürfnissen entsprochen, oder haben Kunden oft Änderungen an dem Gelieferten verlangt?
Erledigt das Team Arbeit, die dann verworfen wird?

Im traditionellen Projektmanagement gibt es normalerweise einen Projektmanager, der für das gesamte Projektmanagement verantwortlich ist, mit den verschiedenen Stakeholdern spricht und plant, wie das Projekt von Anfang bis Ende ablaufen wird. Das Entwicklungsteam sitzt normalerweise darunter und fungiert als Umsetzer, hat aber in der Regel wenig Spielraum, um in die Definition einzugreifen. Das Problem ist, dass diese Sichtweise davon ausgeht, dass die technischen Aspekte dem Business untergeordnet werden müssen, ohne zu berücksichtigen, dass dies bedeuten kann, dass extrem kostspielige Lösungen entwickelt werden oder in manchen Fällen nicht umsetzbare Lösungen implementiert werden. Dies hat direkte Auswirkungen auf das Business. Agile hingegen schlägt vor, dass die technischen und geschäftlichen Teams stärker als Partner zusammenarbeiten, mit der Idee, dass die vorgeschlagene Lösung das Business zufriedenstellt und gleichzeitig technisch machbar ist. Dies erfordert, den Ingenieuren im Team eine prominentere Rolle zu geben, was ihnen ermöglicht, sich wichtig und als Teil des Projekts zu fühlen, engagierter zu sein und bessere Leistungen zu erbringen.

Wie Sie erkennen, ob Agile für Ihr Projekt geeignet ist:

Finden es meine Projektmanager schwierig, die Kosten eines Projekts korrekt zu planen und vorherzusagen?
Hat die von mir entwickelte Software eine gewisse technische Komplexität?
Enthält die Software manchmal Designfehler oder deckt sie bestimmte Anwendungsfälle nicht vollständig ab?
Wirkt das Team unengagiert oder uninvolviert? Kommen alle Ideen vom PM, und wenn der PM nichts vorschlägt, passiert nichts?

Beim Wasserfall-Projektmanagement sind die Arbeitsweise und Prozesse in der Regel gut definiert und werden nicht hinterfragt oder einer kontinuierlichen Überprüfung unterzogen. Wenn es Probleme gibt, werden traditionelle Ansätze wie der Austausch von Personen oder das Hinzufügen weiterer Personen zum Team angewendet. Es gibt jedoch zahlreiche Belege dafür, dass das Hinzufügen von mehr Personen zu einem Projekt, das im Verzug ist, dieses tendenziell weiter verzögert, da die bereits überlasteten Teammitglieder Zeit aufwenden müssen, um die neuen Mitglieder einzuarbeiten, die eine Lernkurve von mehreren Monaten haben können. Agile hingegen legt den Fokus auf die Arbeitsweise und akzeptiert, dass sie nie perfekt sein wird und kontinuierlich überprüft und optimiert werden muss. Dies geschieht durch empirische Methoden, bei denen die Prozessleistung durch Metriken gemessen wird, Anpassungen und Änderungen auf der Grundlage dieser Metriken und der Beobachtungen des Teams während der Retrospektiven in jeder Entwicklungsiteration (die einige Wochen dauern) vorgenommen werden. In Anbetracht der Tatsache, dass wir in einer sich ständig verändernden Welt leben, ermöglicht uns Agile, den Fokus auf die Verbesserung des Prozesses zu legen, um uns an neue Kontexte anzupassen und von neuen Werkzeugen und Arbeitsweisen zu profitieren, sobald sie auftauchen, solange sie für uns sinnvoll sind.

Wie Sie erkennen, ob Agile für Ihr Projekt geeignet ist:

Erlebe ich häufig Verzögerungen bei Projekten und bin mir nicht sicher warum?
Beschweren sich Personen im Team häufig über die Arbeitsweise oder den Prozess?
Hat mein Prozess in den letzten Jahren wenige Veränderungen erfahren?

Der Wettbewerb um Ingenieure ist derzeit ziemlich hoch, und in den letzten Jahren verstärkt sich dieser Trend nur (wenn Sie mit CTOs und technischen Führungskräften sprechen, werden sie Ihnen wahrscheinlich sagen, dass dies eine ihrer größten Sorgen ist). Dies ermöglicht es Entwicklern, bei der Wahl eines Unternehmens immer anspruchsvoller und selektiver zu werden. Das Gehalt ist zwar entscheidend, aber nicht der einzige Grund, warum ein Entwickler wechselt; Dinge wie Technologie, Karriereentwicklungsmöglichkeiten und Teamarbeit werden ebenfalls berücksichtigt. Es stimmt, dass einige Entwickler mit Scrum als Arbeitsweise nicht sehr zufrieden sind, aber es ist schwer zu glauben, dass sie motiviert wären, zu einem Unternehmen zu gehen, das das Wasserfall-Modell der 90er Jahre verwendet. Natürlich ist die Welt der Entwickler heterogen, und es ist schwierig zu verallgemeinern, aber ich würde sagen, dass die meisten Senior-Programmierer (und auch weniger erfahrene) sich für die Methodik interessieren, mit der sie arbeiten werden. Und ich bin sicher, dass es andere gibt, denen es egal ist, aber in diesem Fall sollten wir uns fragen, warum dieses Desinteresse besteht und ob dies die Profile sind, die wir für unser Team wollen.

Wie Sie erkennen, ob Agile für Ihr Projekt geeignet ist:

Ich bin besorgt über die Gewinnung von Talenten und mir ist bewusst, dass Entwickler zunehmend mehr Auswahl haben und mehr als nur ein gutes Gehalt verlangen?

Es kann auch sein, dass die Organisation in dieser Situation ein agiles Framework wie Scrum eingeführt hat, aber das Gefühl besteht, dass die erwartete Verbesserung nicht eingetreten ist. Dies kann und geschieht aus einer Vielzahl von Gründen wie: Mangel an Personen im Team, die Agile wirklich verstehen, Einführung eines für unsere Realität ungeeigneten Frameworks (Scrum ist weit verbreitet, aber nicht die einzige Alternative und oft nicht einmal die empfehlenswerteste, Sie können über verschiedene Alternativen hier lesen), Implementierung von Praktiken ohne Übernahme agiler Werte und Prinzipien (d.h. keine Veränderung der Denkweise), mangelndes Verständnis und mangelnde Unterstützung durch die Führung usw. Wenn Sie mehr darüber erfahren möchten, warum Agile nicht immer funktioniert, können Sie diesen Beitrag lesen.

Zusammenfassend lässt sich sagen, dass Agile darauf abzielt, Änderungen im Projektumfang zu akzeptieren und den Kunden während der Entwicklung einzubeziehen, als besten Weg, um sicherzustellen, dass das erzielte Ergebnis optimal ist (bekannt als Co-Creation). Es unterstreicht auch die Bedeutung der Zusammenarbeit von Technologie und Business als Weg zu den besten Ergebnissen bei kontrollierten Kosten. Und es fördert eine neue Kultur, in der kontinuierliche Verbesserung es ermöglicht, das Business zu optimieren und gleichzeitig auf die Zufriedenheit unserer Kunden und unserer Teams zu achten. Agile ist jedoch auch nicht perfekt, und in den letzten Jahren sind immer mehr Initiativen entstanden, die über die vielen Probleme bei der Umsetzung sprechen und darüber, wie die Philosophie unter Nutzung der Erkenntnisse der 20 Jahre seit der Definition des Agile-Manifests weiterentwickelt werden kann.

Wenn Sie vor dem Dilemma stehen, welche Arbeitsmethodik Sie wählen sollen, ist meine Empfehlung, mit jemandem mit Erfahrung zu sprechen, bevor Sie sich auf eine Wahl basierend auf unsoliden Kriterien einlassen. Eine ungeeignete Methodik kann einem Team Steine in den Weg legen.