Agile vs Wasserfall?

In einer Welt, in der Agilit\u00e4t zur Norm f\u00fcr 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\u00fcr Implementierungsprojekte und die Anpassung eines Produkts bei Kunden traditionelles Projektmanagement interessanter sein k\u00f6nnte als die Verwendung einer agilen Methodik. Und die Wahrheit ist, dass es mir wie eine gute Gelegenheit erschien, dar\u00fcber zu schreiben, was Agile im Vergleich zu traditionelleren Modellen bietet, gerichtet an ein Management-Publikum, das nicht so vertraut mit Agilit\u00e4t ist.

Ich m\u00f6chte also das Warum von Agile (wenn auch nicht sehr tiefgehend) erneut betrachten und einige Fragen stellen, die sich F\u00fchrungskr\u00e4fte stellen k\u00f6nnen, um zu verstehen, ob Agile eine geeignete Philosophie f\u00fcr 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\u00f6sen versucht:

• Beim Wasserfall-Modell fand die \u00dcbergabe an den Kunden normalerweise am Ende des Projekts statt und manchmal an einigen vordefinierten Meilensteinen w\u00e4hrend der Projektplanungsphase. Das Problem war, dass sie feststellten, dass diese Arbeitsweise oft bedeutete, dass das Entwickelte nicht den tats\u00e4chlichen Bed\u00fcrfnissen des Kunden entsprach oder dass sich diese Bed\u00fcrfnisse w\u00e4hrend der Entwicklung ge\u00e4ndert hatten. Dies f\u00fchrte dazu, dass ganze Projekte nach Jahren der Entwicklung verworfen wurden. Um dieses Problem zu l\u00f6sen, f\u00f6rdert Agile h\u00e4ufige iterative Lieferungen, die es erm\u00f6glichen:
  • Dem Kunden fr\u00fchzeitig Mehrwert zu liefern
  • Den Kunden w\u00e4hrend der Entwicklung einzubeziehen, indem Feedback eingeholt wird, um den Kurs anzupassen, und sicherzustellen:
    • 1. dass die L\u00f6sung den Zwecken des Kunden dient. Als wichtige Anmerkung: Agile konzentriert sich auf die Ergebnisse f\u00fcr den Kunden und betrachtet die gelieferte Software als Mittel, um dem Kunden bei der Erreichung dieser Ergebnisse zu helfen;
    • 2. dass das Entwicklungsteam keine Zeit mit Dingen verschwendet, die dem Kunden nicht dienen;
    • 3. dass nicht zu viel Zeit zwischen der Entwicklung und der Validierung durch den Kunden vergeht, da nachgewiesen wurde, dass die \u00c4nderung umso kostspieliger wird, je l\u00e4nger diese Zeit ist (intuitiv l\u00e4sst sich verstehen, dass es viel einfacher ist, ein gestern erstelltes Dokument zu \u00e4ndern als eines, das vor einem Jahr erstellt wurde).

Wie Sie erkennen, ob Agile f\u00fcr Ihr Projekt geeignet ist:

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

Im traditionellen Projektmanagement gibt es normalerweise einen Projektmanager, der f\u00fcr 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\u00fcssen, ohne zu ber\u00fccksichtigen, dass dies bedeuten kann, dass extrem kostspielige L\u00f6sungen entwickelt werden oder in manchen F\u00e4llen nicht umsetzbare L\u00f6sungen implementiert werden. Dies hat direkte Auswirkungen auf das Business. Agile hingegen schl\u00e4gt vor, dass die technischen und gesch\u00e4ftlichen Teams st\u00e4rker als Partner zusammenarbeiten, mit der Idee, dass die vorgeschlagene L\u00f6sung das Business zufriedenstellt und gleichzeitig technisch machbar ist. Dies erfordert, den Ingenieuren im Team eine prominentere Rolle zu geben, was ihnen erm\u00f6glicht, sich wichtig und als Teil des Projekts zu f\u00fchlen, engagierter zu sein und bessere Leistungen zu erbringen.

Wie Sie erkennen, ob Agile f\u00fcr 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\u00e4t?
• Enth\u00e4lt die Software manchmal Designfehler oder deckt sie bestimmte Anwendungsf\u00e4lle nicht vollst\u00e4ndig ab?
• Wirkt das Team unengagiert oder uninvolviert? Kommen alle Ideen vom PM, und wenn der PM nichts vorschl\u00e4gt, passiert nichts?

Beim Wasserfall-Projektmanagement sind die Arbeitsweise und Prozesse in der Regel gut definiert und werden nicht hinterfragt oder einer kontinuierlichen \u00dcberpr\u00fcfung unterzogen. Wenn es Probleme gibt, werden traditionelle Ans\u00e4tze wie der Austausch von Personen oder das Hinzuf\u00fcgen weiterer Personen zum Team angewendet. Es gibt jedoch zahlreiche Belege daf\u00fcr, dass das Hinzuf\u00fcgen von mehr Personen zu einem Projekt, das im Verzug ist, dieses tendenziell weiter verz\u00f6gert, da die bereits \u00fcberlasteten Teammitglieder Zeit aufwenden m\u00fcssen, um die neuen Mitglieder einzuarbeiten, die eine Lernkurve von mehreren Monaten haben k\u00f6nnen. Agile hingegen legt den Fokus auf die Arbeitsweise und akzeptiert, dass sie nie perfekt sein wird und kontinuierlich \u00fcberpr\u00fcft und optimiert werden muss. Dies geschieht durch empirische Methoden, bei denen die Prozessleistung durch Metriken gemessen wird, Anpassungen und \u00c4nderungen auf der Grundlage dieser Metriken und der Beobachtungen des Teams w\u00e4hrend der Retrospektiven in jeder Entwicklungsiteration (die einige Wochen dauern) vorgenommen werden. In Anbetracht der Tatsache, dass wir in einer sich st\u00e4ndig ver\u00e4ndernden Welt leben, erm\u00f6glicht 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\u00fcr uns sinnvoll sind.

Wie Sie erkennen, ob Agile f\u00fcr Ihr Projekt geeignet ist:

• Erlebe ich h\u00e4ufig Verz\u00f6gerungen bei Projekten und bin mir nicht sicher warum?
• Beschweren sich Personen im Team h\u00e4ufig \u00fcber die Arbeitsweise oder den Prozess?
• Hat mein Prozess in den letzten Jahren wenige Ver\u00e4nderungen erfahren?

Der Wettbewerb um Ingenieure ist derzeit ziemlich hoch, und in den letzten Jahren verst\u00e4rkt sich dieser Trend nur (wenn Sie mit CTOs und technischen F\u00fchrungskr\u00e4ften sprechen, werden sie Ihnen wahrscheinlich sagen, dass dies eine ihrer gr\u00f6\u00dften Sorgen ist). Dies erm\u00f6glicht 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\u00f6glichkeiten und Teamarbeit werden ebenfalls ber\u00fccksichtigt. Es stimmt, dass einige Entwickler mit Scrum als Arbeitsweise nicht sehr zufrieden sind, aber es ist schwer zu glauben, dass sie motiviert w\u00e4ren, zu einem Unternehmen zu gehen, das das Wasserfall-Modell der 90er Jahre verwendet. Nat\u00fcrlich ist die Welt der Entwickler heterogen, und es ist schwierig zu verallgemeinern, aber ich w\u00fcrde sagen, dass die meisten Senior-Programmierer (und auch weniger erfahrene) sich f\u00fcr 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\u00fcr unser Team wollen.

Wie Sie erkennen, ob Agile f\u00fcr Ihr Projekt geeignet ist:

• Ich bin besorgt \u00fcber 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\u00fchrt hat, aber das Gef\u00fchl besteht, dass die erwartete Verbesserung nicht eingetreten ist. Dies kann und geschieht aus einer Vielzahl von Gr\u00fcnden wie: Mangel an Personen im Team, die Agile wirklich verstehen, Einf\u00fchrung eines f\u00fcr unsere Realit\u00e4t ungeeigneten Frameworks (Scrum ist weit verbreitet, aber nicht die einzige Alternative und oft nicht einmal die empfehlenswerteste, Sie k\u00f6nnen \u00fcber verschiedene Alternativen hier lesen), Implementierung von Praktiken ohne \u00dcbernahme agiler Werte und Prinzipien (d.h. keine Ver\u00e4nderung der Denkweise), mangelndes Verst\u00e4ndnis und mangelnde Unterst\u00fctzung durch die F\u00fchrung usw. Wenn Sie mehr dar\u00fcber erfahren m\u00f6chten, warum Agile nicht immer funktioniert, k\u00f6nnen Sie diesen Beitrag lesen.

Zusammenfassend l\u00e4sst sich sagen, dass Agile darauf abzielt, \u00c4nderungen im Projektumfang zu akzeptieren und den Kunden w\u00e4hrend 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\u00f6rdert eine neue Kultur, in der kontinuierliche Verbesserung es erm\u00f6glicht, 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 \u00fcber die vielen Probleme bei der Umsetzung sprechen und dar\u00fcber, 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\u00e4hlen 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.