Projekte in SchieflageLesezeit 3 Minuten

Warum agile Vorhaben scheitern – und selten an der Methode

Nach jedem gescheiterten agilen Vorhaben folgt dieselbe Erklärung: Man habe es nicht konsequent genug umgesetzt. Das stimmt selten. Meistens hat das Umfeld nicht mitgespielt, und das war von Anfang an absehbar.

Ein Haus führt agile Methoden ein, baut Teams, besetzt Rollen, kauft Schulungen. Zwei Jahre später ist die Bilanz gemischt bis schlecht. Die gängige Erklärung lautet, man sei nicht konsequent genug gewesen. Das ist bequem, weil sie die Lösung gleich mitliefert: noch mehr Methode.

Ich habe eine solche Umstellung selbst verantwortet: in einem IT-Dienstleister der Versicherungswirtschaft mit rund 600 Mitarbeitenden, wo wir das Anforderungsmanagement nach SAFe neu aufgesetzt, in der Entwicklung auf Kanban umgestellt und ein Organisationsmodell gebaut haben, das den Teams Autonomie geben sollte. Aus dieser Erfahrung halte ich die gängige Erklärung für falsch. Die Teams haben in der Regel ordentlich gearbeitet. Gescheitert sind sie an Rahmenbedingungen, die niemand angefasst hat.

Fünf Gründe, die tatsächlich dahinterstehen

Der Product Owner durfte nicht entscheiden

Von den fünf Gründen halte ich diesen für den teuersten. Die Rolle ist besetzt, der Name steht im Organigramm, aber jede Festlegung, die Geld kostet oder einen Fachbereich berührt, geht zurück in ein Gremium. Damit ist das Herzstück des Vorgehens ausgebaut. Ein Team, das alle zwei Wochen liefern soll, aber auf Entscheidungen vier Wochen wartet, iteriert nicht, es wartet.

Das Vorhaben war zu groß für ein Team und zu eng verzahnt für mehrere

Agil skaliert über Schnitte, nicht über Koordination. Wo sich die Systemlandschaft nicht in Teile zerlegen lässt, die unabhängig geliefert werden können, erzeugt jedes zusätzliche Team mehr Abstimmungsaufwand als Kapazität. Diesen Schnitt macht niemand nachträglich; er ist eine Architekturentscheidung.

Das Umfeld blieb klassisch

Budget wird einmal im Jahr beschlossen, der Vertrag mit dem Dienstleister hat einen festen Umfang, Releases gehen zweimal jährlich in Produktion, und die Abnahme braucht sechs Wochen. In so einem Haus kann ein Team agil arbeiten, das Vorhaben ist es nicht. Die Beweglichkeit endet an der ersten Systemgrenze.

Niemand hat Nein gesagt

Ein Backlog ist kein Wunschzettel, sondern eine Reihenfolge. Wenn alles aufgenommen und nichts verworfen wird, wächst es schneller, als geliefert werden kann. Die Folge ist nicht Verzögerung, sondern Vertrauensverlust: Die Fachseite sieht ihre Anforderung aufgenommen und wartet zwei Jahre.

Gemessen wurde Ausstoß, nicht Wirkung

Velocity, Story Points, abgeschlossene Tickets. Alles Zahlen über die Arbeit des Teams, keine über den Nutzen für das Haus. Nach einem Jahr kann niemand sagen, was das Vorhaben verändert hat, und in dem Moment ist es angreifbar – unabhängig davon, wie gut gearbeitet wurde.

Die Frage, die vor der Methode kommt

Bevor es sich lohnt, über das Vorgehen eines Teams zu sprechen, ist eine Sache zu klären: Darf dieses Team Umfang streichen, ohne vorher zu fragen?

Wenn ja, haben Sie ein agiles Vorhaben, und über Details lohnt es sich zu reden. Wenn nein, haben Sie ein klassisches Vorhaben mit neuen Begriffen, und die Schwierigkeiten, die Sie beobachten, sind nicht die des Vorgehens, sondern die einer Organisation, die sich nicht entschieden hat.

Das ist keine Kritik an agilen Methoden. Es ist der Hinweis, dass ihre wesentliche Voraussetzung keine Methodenfrage ist, sondern eine Frage von Mandat und Vertrauen. Diese Voraussetzung lässt sich herstellen. Nur nicht durch eine Schulung.

← Alle Beiträge