Was ist mit Agile passiert? Ein Leitfaden für Teams außerhalb der USA

9 Min. Lesezeit

Die Frameworks leben, aber etwas ist gestorben

Das Problem, das diese Frameworks lösen sollten

In den 1980er und 1990er Jahren folgten die meisten Software-Projekte dem „Wasserfall” — einem sequentiellen Prozess, der aus der Fertigung übernommen wurde. Analysten sammelten monatelang Anforderungen. Architekten entwarfen das komplette System. Entwickler bauten es. Tester fanden die Fehler. Jahre später erreichte die Software die Nutzer.

Der Begriff „Wasserfall” stammt aus Winston Royces Papier von 1970 „Managing the Development of Large Software Systems.” Aber Royce stellte das sequentielle Modell als fehlerhaften Ansatz dar. Sein Papier warnte, dass diese Methode „riskant ist und zum Scheitern einlädt” und plädierte für iterative Entwicklung mit Feedback-Schleifen.

Die Branche übernahm genau das, wovor Royce warnte, und benannte es nach seinem Papier.

1985 institutionalisierte das US-Verteidigungsministerium diese Fehlinterpretation in DOD-STD-2167 und forderte „sequentielle Phasen eines Software-Entwicklungszyklus.” Das DoD brauchte fast ein Jahrzehnt, um den Kurs zu ändern. 1994 ermutigte MIL-STD-498 ausdrücklich zu „evolutionärer Beschaffung und iterativer, inkrementeller Entwicklung.”

Iterative Entwicklung ist keine neue Erfindung. Gerald Weinberg dokumentierte Teams, die bereits 1957 bei IBM inkrementelle Ansätze verwendeten. Die Praktiken, die zu „agil” wurden, waren keine Entdeckungen — sie waren Wiederentdeckungen.

Das Manifest, veröffentlicht 2001, fasste diese Erkenntnis in vier Wertaussagen zusammen. Scrum lieferte einen Rhythmus kurzer Iterationen. Extreme Programming betonte technische Praktiken: testgetriebene Entwicklung, Pair Programming, kontinuierliche Integration. Kanban konzentrierte sich auf die Visualisierung von Arbeit und die Begrenzung laufender Arbeiten.

Die Frage ist, was zwischen dieser ursprünglichen Erkenntnis und der heutigen Zertifizierungsindustrie passiert ist.

Wer brauchte diese Frameworks eigentlich?

Kleine Teams, die Software-Produkte entwickeln, brauchten nie aufwendige Prozess-Frameworks. Ein Team von fünf Entwicklern, das direkt mit Kunden arbeitet und wöchentlich ausliefert, braucht keine Scrum-Zeremonien, um synchron zu bleiben. Sie brauchen SAFes Koordinationsschichten nicht, weil es nichts zu koordinieren gibt.

Die Frameworks entstanden für große Organisationen mit vielen Teams, komplexen Abhängigkeiten und Management-Ebenen, die weit von der eigentlichen Arbeit entfernt sind.

Das Chrysler Comprehensive Compensation (C3) Projekt beweist, dass disziplinierte Software-Entwicklung auch in großen Konzernen funktioniert. 1993 als Lohnabrechnungssystem für 87.000 Mitarbeiter gestartet, hatte das Projekt 1996 nach drei Jahren traditioneller Entwicklung noch keinen einzigen Gehaltsscheck gedruckt. Kent Beck wurde hinzugezogen und führte zusammen mit Ron Jeffries die Praktiken ein, die zu Extreme Programming wurden.

Innerhalb von etwa einem Jahr nach der Einführung von XP ging das System in Betrieb. Es funktionierte. Entwicklungspraktiken — kein Management-Framework — verwandelten ein gescheitertes Projekt in ein funktionierendes System.

DaimlerChrysler stellte das Projekt 2000 nach der Übernahme von Chrysler ein. Ein Manager verkündete auf der XP-Konferenz, dass DaimlerChrysler „XP de facto verboten” habe.

Die Praktiken, die das Projekt retteten, wurden eingestellt. Nicht weil sie scheiterten, sondern weil sie nicht zur Management-Kultur der übernehmenden Organisation passten.

Die ursprüngliche Krise, die nie endete

Die „Software-Krise” wurde auf der NATO Software Engineering Konferenz 1968 in Garmisch benannt. Software-Projekte überschritten regelmäßig Budget und Zeitplan und funktionierten oft überhaupt nicht. Wie in Überbrückung der großen Kluft dargelegt, geht das grundlegende Missverständnis zwischen technischen und nicht-technischen Menschen auf diesen Moment zurück.

Edsger Dijkstra in seiner Turing-Award-Vorlesung 1972:

„Die Hauptursache der Software-Krise ist, dass die Maschinen um mehrere Größenordnungen leistungsfähiger geworden sind! Um es ganz deutlich zu sagen: Solange es keine Maschinen gab, war Programmieren überhaupt kein Problem; als wir ein paar schwache Computer hatten, wurde Programmieren zu einem leichten Problem, und jetzt, wo wir gigantische Computer haben, ist Programmieren zu einem ebenso gigantischen Problem geworden.”

Software-Entwicklung ist keine Fertigung. Es ist Designarbeit, die nicht so skaliert wie Produktionslinien. Mehr Leute hinzuzufügen macht Projekte oft langsamer, nicht schneller.

Große Organisationen reagierten mit industriellen Managementtechniken: mehr Dokumentation, mehr Phasentore, mehr Trennung zwischen Denken und Tun. DOD-STD-2167 und seine kommerziellen Nachahmer institutionalisierten genau den Ansatz, von dem Praktiker wussten, dass er nicht funktionierte.

Die andauernde Software-Krise — nie gelöst, mit denselben Ausfallraten wie in den 1960er Jahren dokumentiert — erzeugt ständige Nachfrage nach neuen Prozesslösungen. Jede gescheiterte Methodik schafft den Markt für ihren Nachfolger. (Mehr zur Nähe von Management-Frameworks zu Schlangenöl im früheren Artikel.)

Die Ironie ist, dass das ursprüngliche Agile Manifest von Praktikern geschrieben wurde, die explizit management-zentrierte Ansätze ablehnten. Sie schätzten „Individuen und Interaktionen mehr als Prozesse und Werkzeuge.” Das Gegenteil von dem, was die Zertifizierungsindustrie schließlich verkaufte.

Die Zeitleiste der Ernüchterung

Dave Thomas, einer der siebzehn ursprünglichen Unterzeichner des Agile Manifests, in seinem Artikel von 2014 „Agile is Dead (Long Live Agility)”:

„Das Wort ‚agil’ wurde so weit verdreht, dass es praktisch bedeutungslos ist, und was als agile Community gilt, scheint größtenteils eine Arena für Berater und Anbieter zu sein, um Dienstleistungen und Produkte anzupreisen.”

Die öffentlichen Aussagen der Menschen, die diese Ansätze geschaffen haben:

2009: Ken Schwaber, Mitbegründer von Scrum, verlässt die Scrum Alliance nach Meinungsverschiedenheiten über „Assessments, Zertifizierung und ein Entwicklerprogramm.” Er gründet im folgenden Jahr Scrum.org.

2013: Schwaber nennt SAFe „unSAFe at any speed”:

„Die Jungs vom RUP (Rational Unified Process) sind zurück. Aufbauend auf dem tiefgreifenden Scheitern von RUP drängen sie jetzt das Scaled Agile Framework als einfachen, einheitlichen Ansatz für die agile Organisation.”

2014: Dave Thomas erklärt „Agile is Dead” und schlägt vor, den Begriff ganz aufzugeben.

2018: Martin Fowler in seiner Agile Australia Keynote:

„Unsere Herausforderung im Moment ist nicht, Agile zu etwas zu machen, das Menschen tun wollen, sondern mit dem umzugehen, was ich Pseudo-Agile nenne: Agil nur dem Namen nach, aber ohne die Praktiken und Werte.”

Und:

„Der Agile Industrial Complex, der Menschen Methoden aufzwingt, ist eine absolute Tragödie.”

2018: Ron Jeffries veröffentlicht „Developers Should Abandon Agile”:

„Ich möchte, dass die Welt sicher für Entwickler ist… es bricht mir das Herz zu sehen, wie die Ideen, über die wir im Agile Manifest geschrieben haben, dazu verwendet werden, das Leben von Entwicklern schlechter zu machen statt besser.”

Er empfiehlt Entwicklern, „ihr Denken von jeder bestimmten benannten ‚Agile’-Methode zu lösen” und prägt „Dark Agile” und „Dark Scrum” für aufgezwungene, compliance-fokussierte Implementierungen.

Das sind keine Randkritiker. Das sind die Architekten der ursprünglichen Bewegung.

Was sich geändert hat

Die ursprünglichen Manifest-Werte:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Die Zertifizierungsindustrie entdeckte, dass sich die rechte Seite besser verkauft. Prozesse können verpackt werden. Werkzeuge können lizenziert werden. Dokumentation kann Rechnungen rechtfertigen. Pläne schaffen Verträge.

Die linke Seite — Individuen, Interaktionen, Zusammenarbeit, Reagieren auf Veränderung — erfordert Urteilsvermögen und Kontext. Sie widersetzt sich der Standardisierung. Sie skaliert nicht als Produkt.

Die Branche baute aufwendige Frameworks um die rechte Seite herum und beanspruchte dabei den Mantel der linken.

Warum das außerhalb der USA wichtig ist

Die kommerzielle Framework-Maschinerie expandierte global mit einer Verzögerung von etwa fünf bis zehn Jahren. SAFe-Rollouts in Europa beschleunigten sich zwischen 2015 und 2020. Die gleiche Entwicklung, die amerikanische Software-Teams erlebt haben, wiederholt sich jetzt international.

Teams, die sich noch nicht für einen Framework-Kauf entschieden haben, können beobachten, was passiert ist, ohne für die Lektion zu bezahlen.

Die 17. und 18. State of Agile Reports zeigen, dass 42 % der Organisationen jetzt Hybridmodelle verwenden und agile Praktiken mit traditionellen Ansätzen mischen. Teams entdeckten, dass dogmatische Befolgung jedes Frameworks schlechtere Ergebnisse produziert als durchdachte Anpassung an den Kontext.

Die Unterscheidung, die zählt

Die Frameworks bleiben als Diagnosewerkzeuge nützlich. Scrums Zeremonien können Dysfunktionen aufdecken. SAFes Architekturmuster können Integrations-Reibung offenlegen. Kanbans Visualisierung kann Engpässe sichtbar machen.

Das Problem entsteht, wenn das Framework zum Ziel wird statt zur Linse. Wenn „Agile machen” das „Wert liefern” ersetzt.

Die relevante Frage ist nicht „Welches Framework sollten wir übernehmen?” sondern „Welche spezifische Fähigkeit müssen wir entwickeln?”

Was technische Exzellenz erfordert

Wenn die Manifest-Autoren beschreiben, was tatsächlich funktioniert, kehren sie zu technischen Praktiken zurück: testgetriebene Entwicklung, kontinuierliche Integration, Refactoring, Pair Programming, Auslieferung in kleinen Chargen.

Diese Praktiken erfordern keine Zertifizierung. Sie skalieren nicht als Beratungsprodukte. Sie erfordern disziplinierte Anwendung über Zeit.

Martin Fowlers Kritik von 2018 identifizierte drei Herausforderungen:

1. Kämpft gegen den „Agile Industrial Complex”
2. Erhöht die Bedeutung technischer Exzellenz
3. Organisiert euch um Produkte, nicht um Projekte

Beachtet, was fehlt: Framework-Auswahl, Skalierungsmuster, Führungsstrukturen. Der Weg nach vorn ist nicht mehr Methodik. Es ist bessere Software-Entwicklung.

Ein praktischer Standpunkt

Entwicklungspraktiken, die beobachtbare Ergebnisse produzieren: kürzere Durchlaufzeiten, niedrigere Fehlerraten, schnellere Erholung von Vorfällen, echte Nutzerakzeptanz. Diese Metriken kümmern sich nicht darum, welchem Framework ihr folgt. Wie in Management-Frameworks reparieren keine Software-Teams besprochen, diagnostizieren Frameworks Symptome, während Entwickler Ursachen beseitigen.

Bei der Bewertung jeder vorgeschlagenen Praktik oder Transformation: „Was werden wir in der Produktion beobachten können, das wir heute nicht beobachten können?”

Wenn die Antwort Dashboards, Berichte oder Vertrauensabstimmungen beinhaltet statt funktionierender Software in Nutzerhänden, kauft ihr Etiketten statt Fähigkeit.

Die Frameworks sind nicht tot. Aber der semantische Inhalt, der „Agile” einst nützlich machte, ist woandershin gewandert: in die stillen Praktiken von Teams, die häufig ausliefern, auf Evidenz reagieren und Erfolg an dem messen, was ihre Nutzer tatsächlich erleben.

Für Teams außerhalb der USA, die jetzt diese Entscheidungen navigieren: Die Zeremonie produziert nicht das Ergebnis. Die Entwicklungspraktik tut es.

Eine Warnung: Die gleichen Marktdynamiken, die Agile kommerzialisierten, werden wahrscheinlich „Post-Agile”-Alternativen produzieren, die auf Entwicklungsmärkte abzielen. Andere Marken, gleiches Geschäftsmodell — Zertifizierungen, Transformationen, Beraterabhängigkeiten. Die Verzögerung zwischen USA-Adoption und globaler Expansion schafft Arbitrage-Möglichkeiten. Skepsis gegenüber den Etablierten sollte nicht in Vertrauen zu ihren Kritikern-die-zu-Wettbewerbern-wurden umschlagen.

Erst selbst sehen

Bevor ihr Verträge mit Transformationsberatern unterschreibt, überlegt, zu beobachten, was tatsächlich passiert.

Die meisten Führungskräfte, die Entscheidungen über Software-Auslieferung treffen, haben begrenzte Sichtbarkeit in die Arbeit selbst. Sie erhalten Statusberichte, Vertrauensabstimmungen und Velocity-Charts — nichts davon zeigt, ob Software die Nutzer erreicht oder ob Teams mit Integrations-Reibung, unklaren Anforderungen oder technischen Schulden kämpfen.

Caimito Navigator verdichtet, was eure Teams tatsächlich tun — aus täglichen Logbüchern und Auslieferungssignalen — zu wöchentlichen Erkenntnissen, die jeder nicht-technische Manager verstehen kann. Kein Framework-Kauf erforderlich. Keine Zertifizierung nötig. Beobachtete Fakten über eure Auslieferungsrealität.

Der Service beinhaltet Gespräche mit erfahrenen Praktikern, die helfen können, Muster zu interpretieren und gezielte Verbesserungen vorzuschlagen. Kein Kaufdruck, kein Upselling zu Transformationsprogrammen.

Viele Organisationen entdecken, dass ihre Teams bereits wissen, was kaputt ist. Sie brauchen nur jemanden, der dieses Wissen an Entscheidungsträger weitergibt, die Hindernisse beseitigen können. Manchmal ist die wertvollste Intervention kein neuer Prozess — sondern Sichtbarkeit in den Prozess, den ihr bereits habt.