Agile richtig anzuwenden ist eine Kunst – oder doch nicht?

5 Gründe für das Scheitern agiler Methoden
Kommentare

Agile ist einfach? Schön wär’s! Noch immer haben viele Unternehmen Probleme damit, die agile Arbeitsweise richtig um- und einzusetzen. Mal liegt es an der Unternehmenskultur, mal steht die Ungeduld des Managements dem agilen Wandel im Weg. So oder so ist die Enttäuschung groß, wenn die agile Arbeitsweise nicht ins gelobte Land der schnellen, fehlerfreien Softwareentwicklung führt. Eigentlich ist das aber gar kein Wunder.

Es ist wie immer im Leben. Manches liegt einem, anderes einfach nicht so sehr. Wer mit agilen Methoden nichts anfangen kann, lässt sich auch durch die zehnte Schulung nicht zum agilen Superhelden erziehen. Und selbst Menschen, die total begeistert von Agile sind, können noch richtig viel falsch machen:

„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber beim Universum bin ich mir noch nicht ganz sicher.“

Dieses Zitat wird Albert Einstein zugeschrieben; ob er es wirklich gesagt hat, soll uns nun nicht weiter interessieren. Schlussendlich weiß ja jeder Entwickler, dass das Zitat durchaus nah an der Realität ist. Jeder DAU (dümmster anzunehmender User) und Client from Hell beweist erneut, wie viele Fehler selbst bei den einfachsten Aufgaben passieren können. Auch agile Methoden sind davor nicht sicher, sondern können an verschiedensten Faktoren scheitern. Wir haben fünf mögliche Gründe für das Scheitern zusammengetragen.

1. Unternehmenskultur & das Management

Das belegt auch der aktuelle State of Agile Report, den VersionOne in diesem Jahr bereits zum zehnten Mal vorgelegt hat. Demnach ist ein häufig gemachter Fehler in der Umsetzung agiler Methoden der Druck zur gleichzeitigen Beibehaltung von Wasserfall-Methoden. Mehr als ein Drittel der Befragten gab im diesjährigen State of Agile Report an, dass agile Projekte daran scheitern würden. 15 Jahre nach der Veröffentlichung des agilen Manifests ist das eine ganze Menge – immerhin hatten die Methoden ja schon reichlich Zeit, um sich zu verbreiten.

Eine noch größere Hürde stellt die fehlende Unterstützung der agilen Arbeitsweise durch das Management dar; ein Aspekt, der das vorgenannte Problem noch einmal verdeutlicht. Immerhin entscheiden die Führungskräfte darüber, nach welchen Methoden gearbeitet wird. Seit dem Report 2010 haben sich Micromanager und sonstige nicht agile Führungskräfte von Platz sechs der Umfrageergebnisse auf Platz drei der Gründe für agile Misserfolge hochgearbeitet.

Über die Vorteile, Probleme, Chancen und Herausforderungen von Agilität lesen Sie im Entwickler Magazin Spezial Vol. 3: Agilität.

Geschlagen wird dieser Grund fürs Scheitern agiler Projekte nur noch von einem Mangel an Erfahrung im agilen Arbeiten (Platz 2) und einer Unvereinbarkeit der Unternehmenskultur mit agilen Prinzipien auf Platz 1. Und genau da schließt sich der Kreis: Wenn das Management nicht mitzieht, kann sich die Unternehmenskultur nicht verändern; wenn sich die Kultur nicht der agilen Arbeitsweise anpasst, trauen sich Manager nicht, ihre Macht aufzugeben und lassen den Entwicklern nicht die nötige Freiheit, um agil arbeiten zu können. Ein Teufelskreis.

2. Multi-Methoden- und Hybrid Agile

Agile Wasserfälle, „Multi-Methoden-Ansätze“ und Hybrid Agile sind Schlagworte, die hier eine große Rolle spielen. Gemeint ist der Versuch, agile Prinzipien mit klassischen Wasserfall-Organisationsformen zu vereinen. Die dahinterstehende Idee ist komplexer als sie auf den ersten Blick erscheint, obwohl ein Methodenkonflikt ja sogar zum Scheitern von Projekten führt. Immerhin sei am Ende eine individuelle Lösung für jedes Unternehmen nötig, wie Mirco Hering in einem Beitrag zum Thema Hybrid Agile erklärt. Und dabei könnten durchaus Ideen verschiedener Methodiken zum Einsatz kommen.

Dennoch gibt es Warnzeichen für das Scheitern agiler Hybriden, so Hering. Diese sind vor allem dann sichtbar, wenn die Unternehmenskultur nicht zum agilen Arbeiten passt. Auch Hering wiederholt also, was der State of Agile Report belegt. Zu den größten Hürden für agiles Arbeiten gehört für ihn die Trennung zwischen verschiedenen Disziplinen. Das gilt sowohl für Teams, die nur entwickeln oder nur testen, als auch für Iterationen, die nur auf einen Aufgabenbereich (beispielsweise das Design oder die Tests) ausgelegt sind.

Auch wer sich aus der agilen Methodik nur die Meetings herauspicke, könne nicht mit Erfolg rechnen, findet Hering. Vielmehr sagt er, dass in solchen Fällen von hybriden Wasserfällen die Rede sein sollte, nicht von hybriden agilen Methoden. Hybride Agilität entsteht eher dann, wenn Unternehmen aus verschiedenen Frameworks die für sie passenden Ansätze wählen, um ein eigenes Vorgehen zu entwickeln. Die Grundprinzipien des agilen Arbeitens müssen aber jederzeit erfüllt werden.

3. Mangelnde Erfahrung

Jenseits dieser ganz grundlegenden methodischen Probleme benennt der State of Agile Report aber ja auch einen anderen Faktor, der das agile Arbeiten scheitern lässt: Die mangelnde Erfahrung. Dieser Aspekt muss allerdings differenzierter betrachtet werden. Misserfolge gehören zum agilen Arbeiten dazu, genau so wie der Erfolg. Scheitern die ersten Iterationen eines Teams, das die agile Arbeitsweise gerade erlernt, ist das normal; bis zur Perfektion agiler Methoden können mithin sogar Jahre vergehen.

Ein (zu) verbreitetes Phänomen stellt hier das „Agile is for Christmas“-Denken dar. Dabei wird Teams nicht die notwendige Zeit eingeräumt, um die agile Transformation vollständig zu durchlaufen; auch die Unternehmenskultur kann sich nicht verändern. Die agile Methode wird so schnell wieder abgelegt, wie auch die Weihnachtsdekoration – weil sie nicht sofort zum gewünschten Erfolg geführt hat.

DevOps Docker Camp

Das neue DevOps Docker Camp mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

4. Bewertung der Arbeitsgeschwindigkeit

Woran lässt sich aber messen, ob das Team sich in die richtige Richtung bewegt? Diese Frage ist nicht nur im Kontext der agilen Arbeitsweise schwer zu beantworten, sondern immer dann, wenn es um die Arbeit von Entwicklern geht. Die Zahl der gelösten Probleme, der geschriebenen Codezeilen oder die Menge der Bugs im Code – was macht einen guten Entwickler aus? Am Ende geht es natürlich um jeden dieser Faktoren; kurzfristig kann aber keiner davon für sich alleine genommen Auskunft darüber geben, ob eine Methode funktioniert.

Im agilen Arbeiten wird darum gerne die Velocity eines Teams als Maßstab für seinen Erfolg herangezogen, also das gleichbleibend hohe Tempo, mit dem Feature Points bearbeitet werden. Auch diese Geschwindigkeit muss aber erst einmal etabliert werden und hängt danach von vielen Faktoren ab. Gab es große personelle Veränderungen im Team, kann das die Arbeitsgeschwindigkeit stark beeinflussen. Wird nun nur einmal pro Quartal beurteilt, ob die agile Arbeitsweise zum Erfolg führt, kann also schnell ein verzerrtes Bild entstehen.

5. Umgang mit Fehlern?

Andererseits sollte aber auch das Konzept der Fehlertoleranz richtig verstanden werden. Agiles Arbeiten erlaubt es Entwicklerteams ausdrücklich, Fehler zu machen, um daraus zu lernen. Das ist aber keinesfalls so gemeint, dass Bugs einfach aufs Backlog gesetzt werden sollten, um dort zu bleiben bis sie irgendwann einmal gefixt werden. So sammeln sich nur immer mehr und mehr kleine Probleme an, die irgendwann zu einem wirklich großen Hindernis im Projektverlauf werden.

Wie Ilan Kirschenbaum und Oren Kdoshim erklären, verleitet das Aufschieben von Bugs sogar dazu, einfach mal fünfe gerade sein zu lassen – also Fehler bewusst zu ignorieren, statt den Code sauber zu halten. Wenn sich erst einmal eine gewisse Fehlermenge eingeschlichen hat, werden die Mitarbeiter gleichsam nachlässiger darin, hinter sich aufzuräumen. Dann helfen auch keine Iterationen mehr. Also sollte das Lösen von Bugs in jede Iteration mit eingeplant werden. Das Backlog wird auch so lang genug werden.

Agile einfach richtig machen

Agile richtig anzuwenden ist eine Kunst – oder doch nicht? Am Ende geht es nämlich nicht darum, eine einzelne Methode korrekt umzusetzen, sondern vor allem darum, Entwicklern die Freiheiten und Strukturen an die Hand zu geben, die sie brauchen, um sich selbst zu organisieren. Dazu ist häufig ein gewaltiger unternehmerischer Wandel notwendig; gelingt diese Umstellung, läuft es aber irgendwann fast wie von selbst. Bis dahin erfordert der agile Wandel aber viel an Reflexion und Bewusstsein für eigene Verhaltensmuster und Denkweisen, damit der Prozess nicht in eine vorhersehbare Katastrophe führt.

Aufmacherbild: Timebomb made of dynamite on wooden table on black background via Shutterstock / Urheberrecht: Africa Studio

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -