Suche

Agile: der neue, vergiftete Wasserfall?

Michael Thomas

© Shutterstock.com/Meryll

Ist Agile der Wolf im Schafspelz, gar das Wasserfallmodell 2.0? Ja, meint zumindest Amir Yasin, seines Zeichens CTO und Mitgründer von June, einer Plattform, die Personalvermittler und IT-Profis zusammenbringt. Ein Standpunkt, der neben gewissen Sympathien zahlreiche Gegenstimmen provoziert – darunter auch von IT-Urgestein Robert C. Martin („Uncle Bob“).

Alter Wein in neuen Schläuchen

Agile is terrible. Scrum is worse.

Mit diesen Worten leitet Yasin seinen Rant zum Thema Agile ein. Eine noch deftigere Wortwahl zieht sich wie ein roter Faden durch seine gesamte Argumentation, derzufolge sich Agile für Entwickler zu dem entwickelt hat, was einmal das Wasserfallmodell (das seiner Ansicht nach von keinem „geistig Gesunden“ mehr befürwortet wird) war – nur schlimmer.

Yasin glaubt, dass sich die Versprechen von Agile – darunter, dass die wichtigsten Entscheidungen, die zuvor von anderen gefällt wurden, in die Hände der Programmierer gelegt werden – als Trugschluss entpuppt haben. Agile ist für ihn ein Hammer, der für genau einen Einsatzzweck nützlich ist: Wenn man in einer Beratungsfirma arbeitet und auf die Schnelle für einen Klienten, der im Grunde gar nicht weiß, was er will, einen Prototypen zusammenstöpseln muss. Agile als Gelddruckmaschine sozusagen, oder, in Yasins Worten:

No matter what crazy idea the client comes up with, you schedule it, explain the cost and do it if they’re good with it. The client is happy, the consulting company is getting paid, eventually the project gets done. Win win (though the win is heavily in favor of the consulting company).

Die Programmierer sieht er als Nägel, die von eben diesem Hammer getroffen werden: Im Grunde würden sowohl das Wasserfallmodell als auch Agile im Kern auf das Business Driven Development abzielen. Seiner Ansicht nach sind die Entwickler auch bei Agile die Opfer unverrückbarer Entscheidungen, die von der von technischem Verständnis unbeleckten Business-Seite getroffen werden. Entscheidungen, die komme was wolle durchgedrückt werden. Die einzige „Neuerung“ ist für ihn, dass die Entwickler nun komplett selbst für die Ergebnisse verantwortlich sind.

Ein besonderer Dorn im Auge sind Yasin die Scrum-Meetings: Diese sind seiner Meinung nach lediglich gut darin, die als zu langsam arbeitend wahrgenommenen Mitarbeiter bloßzustellen und unter Druck zu setzen. Gleichzeitig, so Yasin weiter, gerät damit häufig das große Ganze eines Projekts aus dem Blickwinkel.

Auch an den „Story Points“ lässt er kein gutes Haar: Zum einen betrachtet er sie als beliebig zugeordnete und zahlenmäßig nicht ausreichende Datenpunkte, die darüber hinaus von vielen Verantwortlichen als „Zeiteinheit“ genutzt werden, um unzulässigerweise die Leistung verschiedener Teams miteinander zu vergleichen. Den Agile-Beratern schließlich wirft er vor, dass diese im Falle des Scheiterns den Fehler immer beim Projekt verorten würden, während sie Agile selbst für unfehlbar halten – bzw. behaupten, Agile sei nicht richtig angewendet worden.

Was also tun? In Umkehrung des Anna-Karenina-Prinzips („Alle glücklichen Familien gleichen einander, jede unglückliche Familie ist auf ihre eigene Weise unglücklich.“), wobei er Prozesse mit den Familien gleichsetzt, geht Yasin davon aus, dass alle Prozesse einzigartig sind und sich holzschnittartige Lösungen deshalb verbieten. Um sich dieser individuellen Situation bewusst zu werden, sollte man sich Yasins Ansicht nach an folgenden Punkten orientieren:

  • Sich von allen „Lasten“ befreien (sprich: Jeden, der mit Agile zu tun hat, vom Scrum Master über den Product Owner bis hin den Agile-Beratern, fallenlassen).
  • Das absolute Minimum an Prozessen identifizieren (z. B. anhand einer Feature-Liste).
  • Nach der Brainstorminphase jeden einbeziehen, der auf irgend eine Art mit der Umsetzung des Features zu tun hat (dabei diskutieren, wie man etwas macht, und nicht, wie lange es dauert).
  • Nur Prozesse hinzufügen, die tatsächliche Risiken reduzieren.
  • Erst ausliefern, wenn wirklich alles erledigt (was sorgsam geschriebenen Code, intensive Tests etc. einschließt).

Sollte man dieser Checkliste folgen, so Yasin weiter, dann sei man agil, ohne „Agile“ zu sein – mit genau dem Minimum an Prozessen, das man braucht. Und nicht mehr.

Agile ist kein Wasserfall!

Starker Tobak, keine Frage. Entsprechend zwiespältig fällt das Echo auf Yasins Artikel aus: Während einige Kommentatoren der Argumentation zumindest teilweise zustimmen, lehnen andere sie in Bausch und Bogen ab. Zu letzteren gehört auch das allseits bekannte IT-Urgestein Robert C. Martin („Uncle Bob“), der Yasins Rant gleich einen kompletten Artikel gegenüberstellt. Seine zentrale Aussage:

Agile is not now, nor was it ever, Waterfall

Abgesehen von den vernünftigen Überlegungen des Schlussteils, so Martin, strotzt Yasins Artikel vor Unwahrheiten und diskreditiert eine Disziplin, die es nicht verdient hat. Bereits dem eingangs vorgebrachten Argument, dass kein geistig Gesunder auf die Wasserfallmethode zurückgreifen würde, widerspricht Martin vehement: Bereits eine kurze Google-Suche sei ausreichend, um sich davon zu überzeugen, dass diese auch heute noch (teilweise mit anderen Methoden vermischt) erfolgreich angewendet werden kann.

Generell, so Martin, wisse Yasin offenbar sehr wenig über die Entstehungsgeschichte von Agile und sei respektlos gegenüber all jenen, die hart dafür gearbeitet haben, ihren Beitrag dazu zu leisten. Auch der Angriff auf die Agile-Berater schmerzt Martin offenbar: Der Übergang zu Agile sei ein schwieriger und alle Unternehmen, die diesen dennoch angingen, seien als mutig zu bezeichnen. Natürlich gebe es auch schlechte Agile-Berater. Aber deshalb alle in einen Topf zu werfen sei einfach ignorant.

In einem Punkt allerdings stimmt Martin mit Yasin überein: Darin, das absolute Minimum an Prozessen zu identifizieren und umzusetzen. Zu diesem Zweck präsentiert Martin seine eigene Checkliste:

  • Das Planungsspiel: Bei manchen Teams reicht eine Feature-Liste oder ein Kanban-Board. Andere brauchen Martin zufolge hingegen das volle Agile-Programm.
  • Testen durch den Anwender: Manche Kunden wollen mit derartigen Tests nichts zu tun haben. Sollte dem nicht der Fall sein, empfiehlt Martin Cucumber- oder FitNesse-Tests.
  • Kleine Releases: Eine Praktik, die Martin jedem Team ans Herz legt.
  • Ganzes Team: Ebenfalls eine Praktik, die Martin zufolge immer passt.
  • Kollektivbesitz: Exklusiven Codebesitz sieht Martin problematisch: Verlässt der entsprechende Mitarbeiter beispielsweise das Team, leiden alle anderen darunter. Deshalb sollten mindestens zwei Personen über den jeweiligen Code Bescheid wissen.
  • Coding-Standards: Geht für Martin Hand in Hand mit dem Kollektivbesitz: Das Team sollte die Ausgestaltung des Codes miteinander absprechen.
  • Nachhaltige Geschwindigkeit: Für Martin gleichen Softwareprojekte einem Marathon. Sprints haben in einem solchen Rahmen nichts zu suchen.
  • Kontinuierliche Integration: Für die meisten Teams gilt Martin zufolge: Die Kontinuierliche Integration zu vernachlässigen grenzt an Wahnsinn.
  • Paarprogrammierung: Ob diese sinnvoll ist, hängt Martins Ansicht nach immer vom individuellen Team ab. Dass Code gegengecheckt wird, hält er jedoch allemal für hilfreich.
  • Einfaches Design: Je einfacher, desto besser – für Martin eine Faustregel.
  • Refaktorisierung: Auch hier gilt für Martin: Je sauberer der Code, desto besser.
  • Testgetriebene Entwicklung: Die Art und Weise, auf die Tests durchgeführt werden, ist in jedem Team bzw. Projekt unterschiedlich. Komplett darauf zu verzichten verbietet sich für Martin jedoch.

Martins Fazit: Nicht jedes Team braucht alle agilen Praktiken, um erfolgreich zu sein. Aber die meisten Teams benötigen zumindest einige davon. Die agile Softwareentwicklung generell zu verteufeln, hält er deshalb für unentschuldbar:

If you are going to impugn the character of good people and good ideas, you’d better do your damned homework.

Aufmacherbild: Water pollution contamination, toxic environment von Shutterstock / Urheberrecht: Meryll

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: