Das Problem mit der Agilität

Inhaltsverzeichnis

Vor über zwanzig Jahren konnte man bereits iterativ-inkrementelle Entwicklungsprozesse beobachten. Sie sind ein Vorläufer agiler Prozesse, die es mittlerweile auch seit mehr als fünfzehn Jahren gibt. Obwohl es Agilität bereits geraume Zeit gibt, ist bis heute die agile Transformation ein Thema. Oft klappt die Transformation auch nicht. Warum?

Agile Verfahren zielen darauf ab, ein erfolgreiches Produkt zu entwickeln. Sie gehen in Iterationen vor. Nach jeder Iteration können Kunden den aktuellen Stand des Produkts nutzen. So bekommt das Team Feedback, welche Features beliebt sind und wie man das Produkt weiterentwickeln kann. Auch das Risiko ist geringer als ohne Iterationen: Es ist jederzeit klar, welche Features in Produktion funktionieren und welche nicht. Ein minimales Produkt kann sehr schnell nach Projektstart live gehen, was das Risiko des Scheiterns und einer Fehlentwicklung weiter reduziert. Auf Basis der bisherigen Geschwindigkeit lässt sich abschätzen, wie viel geschafft ist und wie lange das Team für die weiteren Features brauchen wird. Dabei ist das Team zusammen erfolgreich. Nicht eine einzelne Person trägt die Verantwortung für das Projekt, sondern das gesamte Team.

Agile Methoden reduzieren also das Risiko, führen zu schnellen Erfolgen, ermöglichen eine realistische Planbarkeit und entsprechen einer modernen Teamorganisation. Bei so viel Vorteilen sollte Agilität sich eigentlich von selbst durchsetzen. Aber in der Praxis sind agile Transformationen leider eine Herausforderung.

Erfahrungen

Tatsächlich gab es ein Projekt, an dem der Autor beteiligt war, bei dem die Vorteile der Agilität plötzlich zu Problemen wurden. Agilität hätte durch die frühe Produktivstellung der Software und die Abschätzungen für den weiteren Aufwand frühzeitig offensichtlich gemacht, dass das Projekt deutlich länger brauchen würde als geplant. Eigentlich ist es gut, wenn dieses Risiko frühzeitig offensichtlich geworden wäre. Aber in dieser Organisation hätte das Risiko vermutlich zum Abbruch des Projekts geführt, weil das Team offensichtlich ja der Aufgabe nicht gewachsen ist. Ohne Agilität hat das Projekt zwar die ursprünglichen Ziele nicht erreicht, aber es ist mit einigen politischen Tricks dem Abbruch entgangen und hat zumindest Software in Produktion geliefert.

Das Problem ist nicht der agile Prozess, sondern der Umgang mit dem Feedback, das agile Prozesse liefern. Werden bei Problemen personelle Konsequenzen gezogen oder Projekte abgebrochen, statt das Problem zu analysieren und konstruktiv zu lösen, wie es eine agile Kultur fordert, dann kann es leider sein, dass Verschleiern von Risiken und Verzögerungen sowie politische Spiele die einzige Möglichkeit sind, um ein risikoreiches Projekt durchzuführen.

Ebenfalls hätte Agilität in diesem Projekt für die Karriere des Projektleiters zu Problemen geführt. Um weiterzukommen, müssen Projektleiter Projekte erfolgreich abschließen. Aber in einem agilen Projekt gibt es keinen Projektleiter. Niemand außer dem gesamten Team ist für den Erfolg oder Misserfolg verantwortlich. Das widerspricht klassischen Organisationen, bei denen Manager oder Projektleiter für den Erfolg der Teams verantwortlich sind und dafür auch belohnt oder bestraft werden. Dieses Verständnis muss sich für agile Prozesse grundlegend ändern. Agilität predigt die Verantwortung des Teams – und das auch völlig zurecht. Aber dieser an sich richtige Ansatz ist eben in einigen Organisationen nicht so einfach umsetzbar.

Noch mehr Erfahrungen

In einem anderen Projekt stieß eine agile Projektorganisation auf ein klassisches Produktdesign. Letzteres hat in Quartalsreleases gedacht, während die Projektorganisation alle vierzehn Tage neue Software bereitstellen konnte. Das Feedback der Nutzer zu den 14-tägigen Releases konnte nicht in die Produktplanung einbezogen werden. Oft wäre es möglich gewesen, zunächst ein Feature in einer einfachen Art zu implementieren und erst später das Feature vollständig umzusetzen. So hätten Nutzer das Feature frühzeitig ausprobieren können. Wenn es nicht erfolgreich gewesen wäre, hätte man die Investition in das Feature beenden können. Das ist wichtig, weil die Literatur ("Online Experimentation at Microsoft") zeigt, dass Produktdesigner nur bei höchstens 30 Prozent der Fälle die Beliebtheit eines Features richtig einschätzen. Agilität erlaubt es, statt des Schätzens auf das Feedback der Nutzer zu setzen. Dazu muss sich aber das Produktdesign seiner schlechten Trefferquote klar sein und dann Feedback aufnehmen und einarbeiten.

Und schließlich sind die Motive der an einem Projekt Beteiligten unterschiedlich. Dienstleister wollen sicher den Erfolg des Projekts, aber sie müssen auch Geld verdienen, während Auftraggeber Geld sparen wollen. Die entgegengesetzten Ziele führen zu Konfliktpotenzial. Techniker sind oft mehr an Technologien als am Projekterfolg interessiert. Dazu gibt es auch einen Blog-Beitrag auf heise Developer. Am Ende sind an einem Projekt eine Vielzahl an Personen beteiligt, die ganz eigene Motive haben. Ihnen kann der Projekterfolg sehr wichtig oder eher egal sein. Und manchmal sind einige Beteiligte am Misserfolg des Projekts interessiert, um die eigene Karriere weiterzubringen.

Agilität setzt dem ein Menschenbild entgegen, bei dem alle Teammitglieder am Erfolg interessiert sind. Das ist auch sinnvoll, denn wenn die Motive der Projektbeteiligten nicht stimmen, kann man wenig tun, um das Projekt dennoch zum Erfolg zu führen.

Probleme?

Die oben angesprochenen Probleme liegen in Kultur und Management. Organisationen müssten mit Problemen konstruktiv umgehen, die Rolle von Projektleitern überdenken, das Produktdesign agilisieren und ein positives und konstruktives Menschenbild fördern. Anders gesagt: Agile Prozesse funktionieren nur, wenn Umgebung und Kultur dazu passen. Wenn diese Bedingungen nicht passen, muss man sie ändern. Aber können Softwarearchitekten, Entwickler oder Projektleiter eine Organisation so grundlegend ändern? Auch für Manager sind Änderungen in der Kultur schwierig, denn die Kultur ist fundamental für ein Unternehmen als soziales Gefüge. Die Unternehmen sind mit ihren alten Vorgehensmodellen und ihrer Kultur meistens am Markt gut positioniert, sodass gar kein Druck zum Wandel besteht – schon gar nicht zu einem radikalen Kulturwandel, wenn es doch "nur" um ein Software-Entwicklungsprojekt geht.

Das Problem ist nicht auf Agilität beschränkt. Continuous Delivery treibt die häufige Produktivstellung von Software weiter. Microservices unterstützen Agilität und selbstorganisierte Teams. Wenn Agilität wegen der Kultur nur begrenzte positive Auswirkungen hat, dann gilt das auch für Continuous Delivery und Microservices. Und daher wäre es so wichtig, Agilität zum Erfolg zu machen und die Kultur zu ändern.
Lösung?

Wenn die Unternehmen den grundlegenden agilen Wandel in der Kultur nicht mitmachen, wird das Ergebnis ein mehr oder minder halbherziger agiler Prozess sein. Der Autor sieht jedenfalls keine Möglichkeit, Agilität auf diese Kulturen anzupassen. "Echte" Agilität ist aber leider die Ausnahme. Mit anderen Worten: Agilität funktioniert in der Mehrheit der Fälle nicht, und der Grund ist das Problem in der Kultur.

Und dann wird Agilität auch einfach zu oft falsch verstanden. Teilweise ist Agilität sogar zu "noch mehr Druck" geworden, wie zum Beispiel dieser Artikel auf Spiegel Online zeigt. Das hat mit eigenverantwortlichem Team und konstruktivem Umgang mit Feedback nichts mehr zu tun.

Agile Transition wird auch in den nächsten zwanzig Jahren noch ein Thema bleiben und es wird weiterhin viele "agile" Projekte geben, die in Wirklichkeit eben nicht agil sind.

Vielen Dank an meine Kollegen Björn Behrens, Martin Eigenbrodt, Lutz Hühnken, Martin Kühl, Andreas Krüger, Michael Schürig, Stefan Tilkov, Benjamin Wolf und Oliver Wolf für die Kommentare zu einer früheren Version des Artikels.

tl;dr

Agile Transformation ist seit zwanzig Jahren ein Thema. Weil Agilität zu der Kultur vieler Unternehmen nicht passt, wird es ein Thema bleiben. Auch weiterhin werden die meisten agile Projekte nur halbherzig Agilität umsetzen können. ()