Agile Annahmen die Organisationen immer noch ausbremsen

Fünfzehn Jahre und immer noch dieselben Fehler

Im Jahr 2011 veröffentlichte der Agile-Coach Mike Cottmeyer eine Liste von zwölf Annahmen, die agile Methoden über Ihre Organisation treffen. Die Botschaft war klar: Wer diese Praktiken im falschen Kontext einfuhrt, wird scheitern. Fünfzehn Jahre später machen Organisationen immer noch dieselben Fehler. Sie implementieren Scrum oder SAFe, überspringen die Prüfung, ob die Voraussetzungen erfüllt sind und erklären dann, dass Agilität nicht funktioniert.

Einige dieser Annahmen haben sich als bemerkenswert stabil erwiesen. Andere verdienen einen neuen Blick. Was folgt, ist eine Bewertung, welche Annahmen noch gelten, welche sich verändert haben und worauf Praktiker heute achten sollten.

Die Annahmen, die sich nicht verändert haben

Teamstabilität bleibt notwendig

Die wichtigste Annahme auf der ursprünglichen Liste war, dass Teams über die Zeit zusammenbleiben. Nichts in den letzten fünfzehn Jahren hat diese Erkenntnis geschwächt. Forschungsergebnisse aus Googles Projekt Aristotle und Jahrzehnte der Teamleistungsforschung bestätigen, dass psychologische Sicherheit, gemeinsame mentale Modelle und eine vorhersagbare Velocity Kontinuität erfordern. Organisationen, die Menschen als austauschbare Ressourcen behandeln und sie jedes Quartal zwischen Projekten verschieben, werden weiterhin schlechte Ergebnisse mit agilen Methoden erzielen.

Stabile Teams brauchen auch Menschen, die mehr als eine Sache können. Agilität geht davon aus, dass Teammitglieder spezialisierende Generalisten sind: T-formige Fachleute, die tiefe Expertise in einem Bereich besitzen, aber auch in anderen Disziplinen beitragen können. Wenn jede Person im Team ein enger Spezialist ist, besteht die einzige Möglichkeit, sie auszulasten, darin, ihre Zeit auf mehrere Projekte aufzuteilen. Das zerstört die Teamstabilität, von der Agilität abhängt.

Kundeneinbindung entscheidet nach wie vor über den Erfolg

Die Annahme, dass ein voll engagierter Kunde oder Product Owner in Echtzeit an Entscheidungen teilnimmt, bleibt die am häufigsten verletzte Bedingung in der Praxis. Das Muster wiederholt sich branchenübergreifend: Man ernennt einen Product Owner, der einen anderen Hauptjob hat, gewahrt ihm zwei Stunden pro Woche für das Team und macht dann die Entwickler dafür verantwortlich, dass das falsche Produkt entsteht. Leichtgewichtige Dokumentation und iterative Lieferung funktionieren nur, wenn jemand mit Entscheidungsbefugnis verfügbar ist.

Abhängigkeiten zerstören die Vorhersagbarkeit

Lose Kopplung zwischen Teams und minimale externe Abhängigkeiten bleiben entscheidend. Skalierungsframeworks wie SAFe versuchen, teamübergreifende Abhängigkeiten durch Programminkremente und Abhängigkeitsboards zu managen, aber das Grundproblem besteht weiter. Jede Abhängigkeit ausserhalb der Kontrolle des Teams verursacht Verzögerungen und unterhöhlt die Verantwortlichkeit. Die Teams, die am zuverlässigsten liefern, sind diejenigen, die ihren gesamten Wertstrom besitzen.

Die Annahmen, die sich weiterentwickelt haben

Co-Location ist nicht mehr der Standard

Die ursprüngliche Liste ging davon aus, dass die Teammitglieder im selben Raum sitzen. Der globale Wechsel zu Remote- und Hybridarbeit hat diese Annahme als harte Anforderung weitgehend überholt. Verteilte Teams können mit Agilität erfolgreich sein, vorausgesetzt, sie investieren in die richtigen Werkzeuge und Praktiken. Was sich nicht geändert hat, ist das zugrundeliegende Bedürfnis nach häufiger, reichhaltiger Kommunikation. Teams, die Flurgespräche durch nichts ersetzen, werden unabhängig von der Methodik scheitern.

Produkt- statt Projektdenken ist jetzt Mainstream

Cottmeyer stellte fest, dass Agilität davon ausgeht, dass Teams Produkte statt Projekte liefern. Im Jahr 2011 war das eine Minderheitsposition. Heute ist produktorientiertes Denken zum dominierenden Denkmodell in Softwareorganisationen geworden. Die weit verbreitete Einführung von Produktmanagement-Rollen und Frameworks wie „Escaping the Build Trap“ haben diese Annahme von einer Voraussetzung zur Ambition für die meisten Unternehmen gemacht. Die Herausforderung hat sich verschoben: Es geht nicht mehr darum, Organisationen zu überzeugen, dass Produktdenken wichtig ist, sondern ihnen zu helfen, ihre Finanzierungs- und Governance-Modelle umzustrukturieren.

Die Anforderungen an Talent haben sich verändert

Die ursprüngliche Annahme, dass Agilität „die besten 10%“ an Talent erfordert, verdient Differenzierung. Moderne agile Praktiken, bessere Werkzeuge und ausgereiftere Teamfacilitation-Techniken haben Agilität für ein breiteres Spektrum von Fachleuten zugänglich gemacht. Was weiterhin gilt: Selbstorganisierende Teams brauchen Menschen, die Entscheidungen treffen können, ohne auf Anweisungen zu warten. Die Frage dreht sich weniger um rohes Talent als um Denkweise und die Bereitschaft, mit Autonomie zu arbeiten.

Die Annahmen, die schon immer unvollständig waren

Governance kann nicht ignoriert werden

Agile Methoden vermeiden es bewusst, Governance-Strukturen vorzuschreiben. Cottmeyer kennzeichnete dies als Annahme minimaler Prozess-Governance. In der Praxis können regulierte Branchen wie Banken und Pharma, öffentliche Organisationen und Grossunternehmen Governance nicht einfach wegwunschen. Eine Bank, die Scrum einfuhrt, braucht weiterhin Audit-Trails, Änderungsgenehmigungen und regulatorische Compliance. Die agile Community hat diese Lücke langsam anerkannt. Ansätze wie Disciplined Agile Delivery und Enterprise Kanban bieten mittlerweile Rahmenwerke für die Integration von Governance, ohne die Agilität aufzugeben.

Architektur erfordert vorausschauendes Denken

Die Annahme, dass eine etablierte Architektur bereits existiert, war schon immer eine Lücke in agilen Methoden. Die Antwort ist nicht die Rückkehr zum grossen Vorab-Design. Sie besteht darin, anzuerkennen, dass Architekturentscheidungen langfristige Konsequenzen tragen, die Sprint-fur-Sprint-Refactoring nicht immer beheben kann. Moderne Praktiken wie Architecture Decision Records und evolutionäre Architektur bieten einen Mittelweg zwischen schwerer Vorausplanung und keiner Planung.

Was das für Ihre Organisation bedeutet

Die praktische Erkenntnis hat sich seit 2011 nicht geändert. Bevor Sie ein agiles Framework einfuhren, prüfen Sie Ihre Organisation anhand dieser Annahmen. Wo die Bedingungen erfüllt sind, wird das Framework wahrscheinlich gut funktionieren. Wo sie es nicht sind, stehen Sie vor einer Wahl: die Organisation transformieren oder die Praktiken anpassen. So zu tun, als gäbe es die Lücke nicht, ist die einzige Option, die garantiert zum Scheitern fuhrt.

Weiterführend