Warum wir “agil” vermeiden

Wir bauen gute Apps und Prozesse, die Nutzer sind zufrieden und die Geschäfte laufen. Als Digitalprofis haben wir gelernt, was es braucht um gute Software zu entwickeln. Mit agilen Frameworks gelingt das schneller und nachhaltiger. Wir arbeiten damit und führen unsere Kunden glücklich in die digitale Transformation. Aber das Wort agil versuchen wir inzwischen zu meiden wie der Teufel das Weihwasser. Warum?

Wir finden, das Wort wurde gekapert. Es ist so sehr zum Buzzword geworden, dass es als Synonym gebraucht wird für alles was gerade hip ist. Jeder der sich bewegen kann ist irgendwie agil. Stimmt ja auch. Und wenn etwas rasch, speditiv oder flexibel erledigt werden muss, dann sagt man gern agil. Und wenn jemand eine Offerte haben will, dann kommt es gleich viel besser rüber, wenn die Vorgehensweise agil genannt wird.

Agilität für alles

Nein, es braucht keine Ausrede um schlampige Arbeit zu verschönifizieren. Lücken werden nicht besser, wenn man vesucht, sie mit agiler Arbeitsweise zu begründen. Das ist Etikettenschwindel. Anforderungsmanagement, Spezifikation und Analyse braucht es auch bei agiler Arbeitsweise.

Nein, wir stehen nicht den ganzen Tag an einer Wand mit bunten Klebezettelchen und spielen Bauerntheater. Diese Klebezettelchen sind wunderbar. Zumindest wenn Schatzi den Kaffee nicht vergessen soll oder Mausi für die Prüfung lernt. Aber wir spielen kein Theater. Kein Team ist “agiler”, wenn es bunte Zettelchen herumschiebt.

Wir gehen locker und respektvoll miteinander um, tragen Jeans, trinken Bier und lieben das online meeting von unterwegs. Auch das ist genauso viel oder wenig agil wie jeder andere Arbeitsstil auch.

Jeder, der dem Internet ein wenig Content beifügen will, schaut was gerade so angesagt ist. Das Wort agil ist der Cat Content der Businessnetzwerke. Es ist irgendwie süss, nicht sperrig, keine Abkürzung und tönt vertraut und aufgestellt.

Somit wurde ein Begriff der Softwareentwicklung verwässert, überinterpretiert, banalisiert und seiner Konzeptidee beraubt. Das frühe Integrieren, die iterativen Sprints, der Versuch von kleinen Häppchen, die Priorisierung von Anforderungen und die Suche nach dem MVP haben alle eines gemeinsam: Software läuft durch eine lange schwierige Pipeline. Bis sie da durch ist, hat sich die Welt schon wieder weitergedreht. Nichts ändert schneller als das Digitale.

Im kostenlosen, leicht zu lesenden Scrum Guide (der agilen Bibel) finden sich Sätze, die jeder verstehen kann. Die ganze Filosofie dahinter ist so formuliert, dass es sich liesst wie ein Kochrezept, so als könnte man das in jeder Arbeitssituation irgendwie brauchen. Da haben sich die Verfasser wohlmöglich selbst ein Bein gestellt. Wenn man nicht wüsste, dass es sich um eine Methodologie der Softwareentwicklung handelte, könnte man es auch für ein Gurubuch für ein besseres Berufsleben halten.

Stimmt auch. Teilweise. Man kann auch Websites mittels Scrum entwickeln und pflegen, man kann E-Books oder Bildungsangebote so erstellen und aktuell halten und auch sonst noch eine ganze Reihe von digitalen Produkten bauen, die einen Lifecycle haben.

So übersieht so mancher eifrige selbst ernannte Coach, dass es sich um ein methodisches Rahmenwerk zur Softwareentwicklung handelt.

Genau wie das Urwort agil haben sich mittlerweile auch die Bestandteile seiner Methoden im Allgemeinsprech etabliert. Und werden ebenso interpretiert und banalisiert und so zur Sosse von angesagten Coachingweisheiten verrührt.

Kein Wunder, dass sogar erfahrene Software-Tester glauben, dieses ganze Agil-Gerede sei ein Mythos. Da kommen die Berater mit ihren Zertifikaten mit Stempeln und Auszeichnungen, machen Standups, Reviews und Retros, sacken Honorare ein und am Ende ist viel Zeit verbraten ohne dass sich am Entwicklungsprozess gross was geändert hätte.

Die Tests laufen genauso wie vorher, bloss dass der Projektleiter jetzt PO, PIO oder SM heisst und das Release reist mit dem Train statt mit dem Bus. Releases werden orchestriert statt gemanaged und statt dem planung.xls hat man nun ein Digiboard. Die Planung war schon zuvor keine Planung, aber man kann das Excel-Sheet ja nicht mit dem Filenamen hoffnung.xls herumschicken. Aber wenn alles SAFe ist, dann ist alles besser. Nicht?

Agil ist keine Wunderwaffe und kein Allheilmittel für berufliche Führung, Planung oder Organisation. Und nein, sie wurde nicht von der Softwareentwicklung übernommen und geprooft. Es ist umgekehrt. Eine Sammlung von Erfahrungen, Regeln und technischen Rollen, die sich oft schmerzhaft in der Anfangszeit der Programmierung ergeben haben, als man versuchte ingenieurmässiges Arbeiten zu adaptieren, wurde zu einem konsistenten Rahmenwerk zusammengefügt.

敏捷

Die Verfasser der agilen Vorgehensweisen haben sich bemüht, einfache Worte zu benutzen und kein Fachchinesisch wie etwa DevOps, Lifecycle, Deployment oder Bugtracking. Das Wort Projekt wird bewusst vermieden, da wir gelernt haben, dass Softwareentwicklung keinen Projekt-Charakter hat. Und explizit zu sagen, dass Software eigentlich nie fertig wird oder niemals fehlerfrei sein kann, wollte man eben doch nicht. Dann nimmt man ein Wort aus dem allgemeinen Sprachgebrauch und das Wort Produkt passt noch am ehesten. Aber dieses Produkt ist immer ein digitales Produkt, eine Software.

Und ja, Unternehmen werden erfolgreicher mit einem solchen Produkt. Dann wenn es gut ist. Ob das auch agil ist, ist egal.