Agile Entwicklung tot?

In diversen Medien tauchen seit geraumer Zeit Artikel auf, die erklären warum agil tot ist, nicht tot ist, warum die in einer Studie genannten Ausfallraten stimmen bzw. nicht stimmen und ob wir jetzt agile Software Entwicklung hassen oder nicht hassen.

Was sie häufig gemeinsam haben ist die Tatsache, dass die Artikel nicht von Entwicklern geschrieben wurden. Sie basieren idR. alle auf diesem Artikel zum Thema.

Als Erstes können wir dazu mal etwas klarstellen. Das absolute Gros der agilen Softwareentwicklung - insb. in Konzernen - ist nicht mal ansatzweise agil. Es ist ein aufwendiger Affenzirkus über den parasitäre Geschäftsmodelle ihre Existenz finanzieren, in dem Managern Tools verkauft werden und Entwicklern von (idR.) Nicht-Entwicklern erklärt wird wie Entwicklung funktioniert. Natürlich auch ganz generell und für jedes Projekt einheitlich.

Hierbei geht es nicht um agile Softwareentwicklung sondern um den Verkauf von Dienstleistungen und Produkten. Und bedauerlicherweise sind sie darin tatsächlich qualifiziert, denn sie wissen wie sie das Management um den Finger wickeln. Diese agile Entwicklung ist was Manager sich optimal darunter vorstellen. Sie hat absolute nichts mit agiler Entwicklung zu tun.

Entwickler haben kein Problem mit agiler Entwicklung sondern dem Mist, was diese Vertriebler und Firmen daraus machen. Denn den Firmen passen diese wenig agilen Methoden gut ins Konzept. Man kann vorgeben agil zu sein, erhöht auch irgendwie meistens den Output und hat trotzdem noch den ganzen schönen Kontrollfreak Ballast an Bord.

Wer vorgeblich agil entwickelt und sich regelmäßig fragt wieso er eigentlich in diesem Meeting sitzt oder warum X in dem Meeting sitzt, dann arbeitet man nicht agil. Man ist auch nicht agil, wenn man Scrum nutzt. Scrum ist eine mögliche Form die agile Arbeit zu organisieren. Eine von vielen.

Entwickler, die agile Entwicklung hassen, hassen sie idR. weil sie nicht agil arbeiten. Sie sitzen in sinnlosen Meetings, werden von Personen belästigt, die keine relevante Funktion haben, arbeiten unter technischen und organisatorischen Bedingungen, die starrer kaum sein könnten und die obendrein niemand braucht. Diese Form agiler Entwicklung ist Kontrollwahnsinn gepaart mit einer exorbitanten Zeitverschwendung. Mehr schafft man idR. auch nicht wirklich. Wie auch? Der Unterschied liegt idR. nur in der Frequenz mit der man Funktionen ausrollt. Das passiert eben auch in diesen Varianten schneller. Vorausgesetzt man fällt nicht unter die 268%.

Und daher kommt es dann auch, dass diese Studie sehr unterschiedlich wahrgenommen wird. Wer tatsächlich agil ist, dem ist nicht so ganz klar was da schief laufen könnte und wie man auf derartige Zahlen kommt. Wer das oben Erwähnte täglich mitmacht, der weiß das ganz genau.

Es gibt Projekte, bei denen agile Entwicklung ausgeschlossen ist. Das Gros ist aber bestens damit umsetzbar und man kann die erheblichen Vorteil davon nutzen. Das setzt aber eben voraus, dass man auch tatsächlich agil ist. Wie man das ist spielt letztendlich keine Rolle. Die sinnvollste Variante (bei Kundenbeteiligung) ist es eine bestehende agile Methode an die realen Bedingungen des Projekts anzupassen und so agiler zu machen. Wer das Kundenproblem nicht hat, hat die freie Wahl.