Warum agile Methoden nicht mehr agil sind

Wenn die Revolution zum Establishment wird

Das Agile Manifest entstand als Rebellion. Im Jahr 2001 dominierten schwergewichtige Methodologien die Softwareentwicklung. Wasserfallmodelle, aufwendige Spezifikationsdokumente und starre Phasenmeilensteine verwandelten Projekte in bürokratische Ausdauerprüfungen. Siebzehn Praktiker trafen sich in Snowbird, Utah und schlugen etwas Radikales vor: Individuen über Prozesse stellen, funktionierende Software über Dokumentation, Zusammenarbeit über Verhandlung und Veränderung über Planverfolgung.

Die Rebellion war erfolgreich. Agile hat gewonnen. Umfragen zeigen durchgehend, dass die Mehrheit der Softwareorganisationen angibt, agile Methoden zu verwenden. Die Sprache der Sprints, Standups und Backlogs hat Vorstandsetagen, Personalabteilungen und Behörden durchdrungen.

Doch der Erfolg brachte ein Problem mit sich, das die ursprünglichen Autoren nicht vorhergesehen hatten. Die Bewegung, die sich durch die Akzeptanz von Veränderung definierte, wurde bemerkenswert resistent gegenüber der eigenen Weiterentwicklung.

Wie wurde Agile starr?

Andy Hunt, Mitautor des Agile Manifests und von The Pragmatic Programmer, identifizierte das Kernparadox 2015. Agile Methoden, schrieb er, seien selbst nicht agil gewesen. Die kanonischen Praktiken populärer Frameworks blieben im Wesentlichen über ein Jahrzehnt lang unverändert. Die Bewegung erstarrte.

Diese Erstarrung hat nachvollziehbare Gründe. Als Agile neu war, waren seine Praktiken Vorschläge innerhalb eines philosophischen Rahmens. Mit zunehmender Verbreitung verhärteten sich diese Vorschläge zu Vorschriften. Schulungsprogramme kodifizierten sie. Zertifizierungsstellen prüften sie ab. Beratungsunternehmen verkauften sie als Pakete. Die Praktiken wurden zu Produkten, und Produkte brauchen Stabilität, um zu skalieren.

Eine Scrum-Master-Zertifizierung lehrt beispielsweise einen spezifischen Satz von Events, Artefakten und Rollen. Diese Spezifität macht die Zertifizierung lehrbar und prüfbar. Sie macht sie aber auch spröde. Ein zertifizierter Praktiker lernt, wie Scrum aussieht, aber die Zertifizierung kann ihm nicht beibringen, wann Scrum anders aussehen sollte.

Das Zertifizierungsparadox

Zertifizierungen erfüllen ein echtes Bedürfnis. Organisationen, die für agile Rollen einstellen, wollen Kompetenzbelege. Praktiker wollen Referenzen, die ihre Expertise signalisieren. Der Markt reagierte mit standardisierten Bewertungen, die an standardisierte Praktiken gebunden sind.

Die unbeabsichtigte Konsequenz ist, dass das Zertifizierungsökosystem Konformität belohnt. Eine PSM-Pruefung zu bestehen erfordert die Kenntnis des Scrum Guide, nicht das Wissen, wann man davon abweichen sollte. Das prägt, wie Praktiker über ihre Arbeit denken. Das Framework wird gleichzeitig zu Boden und Decke.

Wie Unternehmens-Agile wirklich aussieht

Betreten Sie ein grosses Unternehmen, das „agil geworden“ ist, und Sie finden oft ein vertrautes Muster. Teams führen zweiwöchige Sprints durch. Sie halten tägliche Standups von genau fünfzehn Minuten ab. Sie verwalten Backlogs in Jira. Sie schätzen in Story Points. Sie halten jeden zweiten Freitag Retrospektiven ab.

Betrachten Sie ein typisches Transformationsszenario. Ein Finanzdienstleister führt Scrum in vierzig Entwicklungsteams ein. Jedes Team folgt derselben Sprint-Kadenz, nutzt denselben Jira-Workflow und wendet dieselbe Definition-of-Done-Vorlage an. Das Regulatory-Compliance-Team, das an einem zweijährigen Audit-Zyklus arbeitet, operiert mit derselben zweiwöchigen Sprint-Struktur wie das Mobile-Banking-Team, das wöchentlich Features ausliefert. Keines der beiden Teams hat diese Kadenz gewählt. Sie wurde für sie während eines Transformationsworkshops achtzehn Monate zuvor festgelegt.

Hunt nannte dieses Muster „flaccid agile.“ Teams übernehmen eine bequeme Teilmenge von Praktiken, ignorieren diejenigen, die Disziplin oder Unbequemlichkeit erfordern und erklären sich für agil. Die Standups finden statt, aber niemand ändert den Kurs aufgrund dessen, was dort gesagt wird. Die Retrospektiven finden statt, aber dieselben Probleme tauchen Monat für Monat wieder auf.

Den ursprünglichen Geist zurückgewinnen

Das erste Prinzip des Manifests lautet: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.“ Nichts in diesem Satz erwähnt Sprints, Standups oder Story Points. Das sind Implementierungsentscheidungen, keine Werte.

Den ursprünglichen Geist von Agile zurückzugewinnen erfordert die Trennung der Werte von den Vehikeln. Die Werte sind zeitlos: auf Veränderung reagieren, eng zusammenarbeiten, häufig liefern, ehrlich reflektieren. Die Vehikel sind kontextabhängig: Sie sollten ausgewählt, angepasst und verworfen werden, je nachdem, ob sie den Werten in einer bestimmten Situation dienen.

Was evidenzbasierte Agilität bedeutet

Hunt schlug vor, alle Prozessentscheidungen auf Evidenz aus der realen Welt unter tatsächlichen Bedingungen zu stützen. Das klingt offensichtlich, bis Sie erkennen, wie wenige Teams es tatsächlich tun. Die meisten Prozessentscheidungen in agilen Organisationen basieren auf dem, was das Framework vorschreibt, was ein Berater empfohlen hat oder was ein anderes Team tut.

Evidenzbasierte Praxis bedeutet, jede Praktik als Hypothese zu behandeln. „Wir glauben, dass tägliche Standups die Koordination verbessern. Testen wir diese Annahme anhand unserer tatsächlichen Liefermetriken.“ Ein Team, das dieses Experiment durchführt, könnte feststellen, dass drei Standups pro Woche dieselben Koordinationsvorteile bei weniger Meeting-Muedigkeit bringen. Ein anderes Team könnte feststellen, dass asynchrone Check-ins für sein verteiltes Setup besser funktionieren.

Die Estimation-Progression veranschaulicht dies gut. Ein Anfängerteam folgt Planning Poker, weil die Regeln es vorschreiben. Ein kompetentes Team nutzt Schätzungen, um Meinungsverschiedenheiten über Umfang und Komplexität aufzudecken. Ein Expertenteam könnte formale Schätzungen gänzlich aufgeben, weil sein historischer Throughput bessere Prognosen liefert als Story Points es je konnten. Jede Stufe repräsentiert ein tieferes Verständnis dessen, wofür Schätzungen eigentlich da sind.

Lokal anpassen, global denken

Eine der schädlichsten Annahmen in der modernen agilen Einführung ist, dass alle Teams auf dieselbe Weise arbeiten sollten. Unternehmenstransformationsprogramme rollen typischerweise ein einzelnes Framework über Dutzende von Teams aus, unabhängig davon, was diese Teams entwickeln, wer ihre Nutzer sind oder welchen Einschränkungen sie gegenüberstehen.

Das ursprüngliche Manifest machte keine solche Annahme. „Inspect and adapt“ ist von Natur aus lokal. Was für ein Team funktioniert, das eine Consumer-Mobile-App entwickelt, wird nicht für ein Team funktionieren, das ein regulatorisches Compliance-System wartet. Was für ein co-lokalisiertes Team von sechs Personen funktioniert, wird nicht für ein verteiltes Team von zwanzig funktionieren.

Lokale Anpassung zuzulassen erfordert Vertrauen. Es erfordert Manager, die glauben, dass die Teams, die der Arbeit am nächsten sind, am besten positioniert sind zu entscheiden, wie sie zu erledigen ist. Es erfordert Organisationen, die Ergebnisse über Prozesskonformität stellen. Das sind kulturelle Veränderungen, die kein Framework allein bewirken kann.

Das Agile Manifest waren vier Werte und zwölf Prinzipien, geschrieben auf ein Whiteboard in Utah. Es war nie als Franchise-Betrieb gedacht. Die Bewegung, die es angestossen hat, wird ihren Weg nach vorne finden, wenn Praktiker aufhören zu fragen „Machen wir Agile richtig?“ und anfangen zu fragen „Bauen wir das Richtige, auf die richtige Art, für die Menschen, die es brauchen?“

Weiterführend