In letzter Zeit wünschen sich immer mehr Entwickler eine agile Vorgehensweise. Mehr und mehr Firmen, vor allem junge Startups, werben mit einem agilen Entwicklungsprozess. Doch ist ein derartiger Prozess wirklich sinnvoll? Dem gehen wir heute auf die Spur!

Was ist überhaupt Agil?⌗

Agile ist ein Entwicklungsprozess. Das heißt, es gibt vor, wie man als Entwickler zu arbeiten hat. Die Grundidee hinter Agile war, dass Kommunikation ein sehr hilfreiches und starkes Werkzeug ist. An dieser Idee ist ja auch nichts auszusetzen. Kommunikation kann sehr viel dabei helfen, Fehler zu vermeiden und die Wünsche eines Kunden zu erfahren.

Allerdings wurde Agile in den letzten Jahren extremisiert und ins Abstruse gezogen. Hier sind einige Punkte, die an Agile vollkommen kaputt sind und den Prozess unnütz machen:

Zu viele Meetings⌗

Agile bedeutet vor allem Eins: Meetings. Unheimlich viele Meetings. Ein typischer agiler “Sprint” geht über 2 Wochen. In diesen 2 Wochen hat man oft die folgenden Meetings:

  • Standup: Ein kurzes Meeting, indem darüber gesprochen wird, was man seit dem letzten Standup erreicht hat und was man bis zum nächsten Standup vor hat. Klingt nach einer genialen Idee (immerhin kann man damit überprüfen, dass die Mitarbeiter auch wirklich arbeiten statt im Homeoffice zu zocken), hat aber einen starken Nachteil: Es findet täglich statt! Das ist eine unheimliche Zeitverschwendung. Wenn jeder Mitarbeiter in diesem Standup 3 Minuten redet, sind das in einem 10 Personen Team mindestens 30 Minuten. Insgesamt sind das 300 Minuten verbrauchte Zeit, das entspricht 5 Arbeitsstunden! In dieser Zeit hätten locker 2 neue Features implementiert werden können.
  • Retrospektive: Ein Meeting, in dem man über Konflikte und psychische Probleme der letzten beiden Wochen spricht. Das hat im Arbeitsumfeld nichts zu suchen und sollte eher mit einem Psychiater besprochen werden. Eine Retrospektive dauert bei vielen Teams bis zu 4 Stunden jede 2 Wochen. Das ist ein unakzeptabler Zeitverbrauch dafür, dass der Arbeitgeber hier quasi kostenlose psychologische Beratung anbietet.
  • Demo: Dieses Meeting findet ebenfalls alle 2 Wochen statt. Hier versucht das Team, ihre Arbeit in möglichst gutem Licht dastehen zu lassen und diese dem Kunden zu zeigen. Die Demo wäre eines der wenigen Meetings in dieser Liste, das sinnvoll ist, wäre da nicht ein kleines Problem: Die Entwickler wissen meistens, dass ihre Arbeit nicht ausreichend gut war. So zeigen sie nur die Teile, die sie 3 Minuten vor der Demo noch repariert haben. Sie zeigen genau den einen Pfad durch die neue Anwendung der gut funktioniert. Alles andere wird totgeschwiegen.
  • Planning: Ein typisches Meeting das an der falschen Ecke spart. Auch dieses Meeting findet wöchentlich statt. Hierbei müssen die Mitarbeiter des Teams ausbaden, dass die Architekten und Planer davor ihre Arbeit nicht geleistet haben. Sie müssen Arbeitspakete zusammenstellen und in ihre Arbeitszeit einplanen. Wenn man das im Vorhinein gemacht hätte, hätte man sich viel Arbeitszeit der Entwickler sparen können.

Wie man sieht, verschwenden die Entwickler viele Stunden jede Woche mit Meetings. In der selben Zeit könnten unfassbar viele Features implementiert werden.

Keine richtigen Deadlines⌗

Ein weiteres Problem ist, dass durch Agile Entwicklungsmethoden die Bedeutung einer Deadline verwässert wird. Das passiert aus zwei Gründen:

  1. Die “sanfte” Deadline alle 2 Wochen führt durch Gewöhnungseffekte dazu, dass die Deadline nicht mehr ernst genommen wird. Außerdem führt es dazu, dass bei Deadlines geschummelt wird. Bei einer “unwichtigen” Deadline ein bisschen zu schummeln wird völlig normal.
  2. Agile basiert explizit darauf, oft ein bisschen was fertig zu stellen, aber niemand plant mehr, wann man alles fertigstellen will.

Das führt dazu, dass man gar keine harten Deadlines mehr hat. Alles wird unplanbar, da man nicht mehr festlegt, wann das Gesamtprodukt fertig sein soll. Dieser Schritt führt dazu, dass agile Projekte oft in einer Art “ewiger Entwicklung” enden. Das Produkt wird nie fertig, weil nie gesagt wurde, wann das Produkt fertig ist. Statt feste Anforderungen an Features zu haben und das Produkt verkaufen zu können sobald die Features implementiert wurden, kommt man oft in eine Spirale aus “das Feature ist fertig - hier sind noch 3 neue, die ich gerne hätte!”.

Fazit⌗

Agile wäre eine prima Erfindung, wenn es keine schlechte Erfindung wäre. Durch Meetings und das fehlen von harten Deadlines arbeiten die Entwickler maximal langsam und ineffizient. Alle Vorteile, die durch die zusätzliche Kommunikation dazu kommen, gehen durch die extreme Zeitverschwendung verloren.

Wir müssen eine neue Vorgehensweise finden, die die Vorteile von Agile mit der Planbarkeit und Zeiteffizienz von Waterfall kombiniert.