"Agile ist tot – Es lebe Agile"

August 2025 8 Min. Lesezeit Meinung

Das Wort „Agile” wurde so weit von seiner ursprünglichen Bedeutung entfernt, dass es nahezu wertlos geworden ist. Es bedeutet heute alles – und damit nichts. Und das ist ein Problem, über das man ehrlich reden muss.

Der Einstieg: Ein Wort, das seine Bedeutung verloren hat

Im Februar 2001 trafen sich siebzehn Softwarepraktiker in einem Skiresort in Snowbird, Utah. Sie waren frustriert. Nicht von der Technologie. Nicht von ihren Kunden. Von der Art und Weise, wie Software gebaut wurde – den starren Prozessen, der aufgeblähten Dokumentation, der Diskrepanz zwischen dem, was Kunden wirklich brauchten, und dem, was Entwicklungsteams zu liefern aufgefordert wurden.

Sie formulierten vier Leitsätze und zwölf Prinzipien. Sie nannten es das Agile Manifesto. Es dauerte zwei Tage.

Vierundzwanzig Jahre später steht das Wort, das sie wählten – Agile – auf den Visitenkarten von Beratern, die noch nie eine Zeile Code geschrieben haben. Es taucht in den Berufsbezeichnungen von mittleren Managern auf, deren wichtigster Beitrag zur Softwareentwicklung darin besteht, an Meetings über Meetings teilzunehmen. Es ist Gegenstand einer globalen Zertifizierungsindustrie im Wert von Milliarden Dollar jährlich. Kurz gesagt: Es ist überall.

„We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value individuals and interactions over processes and tools.” The Agile Manifesto, 2001

Lies das nochmal. Individuals and interactions over processes and tools. Schau jetzt auf deine Organisation. Zähle die Prozesse. Zähle die Tools. Zähle die Menschen, deren Aufgabe es ist, die Prozesse und die Tools zu verwalten. Frag dich ehrlich, ob sich das Gleichgewicht verschoben hat.

---

Die Realität: Was aus Agile geworden ist

Das ist, was „Agile” in den meisten Organisationen heute bedeutet. Zweiwöchige Sprints. Ein Daily Standup, dem niemand zuhört. Ein Backlog mit 300 Einträgen, der jeden zweiten Dienstag von einem Product Owner verfeinert wird, der keine echte Befugnis hat, Prioritäten zu setzen. Ein Scrum Master, dessen Hauptaufgabe darin besteht, den Raum für die Retrospective zu buchen und das Jira-Board zu aktualisieren.

Es bedeutet, in der Sprache der Anthropologie: Cargo Cult Agile – die getreue Reproduktion von Ritualen, deren ursprünglicher Zweck vergessen wurde, in der Hoffnung, dass die Ergebnisse irgendwie folgen werden.

Die Zahlen sprechen eine klare Sprache

Der State of Agile Report – die umfassendste jährliche Umfrage zur Agile-Adoption – zeigt konstant, dass die überwiegende Mehrheit der Organisationen angibt, Agile zu praktizieren. Er zeigt aber auch konstant, dass zu den größten Herausforderungen bei der Agile-Einführung folgende gehören:

• Organisationskultur im Widerspruch zu Agile-Werten – von über 40 % der Befragten Jahr für Jahr genannt
• Fehlende Unterstützung durch das Management – das Commitment der Führung, das die Autoren des Manifests als unverzichtbar betrachteten
• Unzureichende Ausbildung und Schulung – Teams, die Scrum praktizieren, ohne zu verstehen warum
• Widerstand gegen Veränderung – die eine Herausforderung, die kein Framework, keine Zertifizierung und kein Berater von außen lösen kann

Lies diese Herausforderungen genau. Es sind keine technischen Probleme. Es sind keine Prozessprobleme. Es sind kulturelle und organisatorische Probleme. Und kein noch so gutes Sprint Planning wird sie lösen.

Die unbequeme Wahrheit: Die meisten Organisationen, die behaupten, Agile zu sein, sind es nicht. Sie haben das Vokabular, die Zeremonien und die Tools übernommen. Die Werte haben sie nicht übernommen. Und ohne die Werte sind die Zeremonien nur Overhead.

---

Der Checksum: Was das Manifest wirklich gesagt hat

Gehen wir zur Quelle zurück. Das Agile Manifesto hat vier Leitsätze. Keine Frameworks. Keine Rollendefinitionen. Keine Sprint-Zeremonien. Vier Aussagen darüber, wo die Priorität liegt, wenn beide Seiten in Konflikt geraten:

Wir schätzen…	Mehr als…
Individuals and interactions	Processes and tools
Working software	Comprehensive documentation
Customer collaboration	Contract negotiation
Responding to change	Following a plan

Das Manifest ist eindeutig: „Das heißt, obwohl wir die Dinge auf der rechten Seite schätzen, schätzen wir die Dinge auf der linken Seite mehr.”

Das ist keine Ablehnung von Prozessen, Dokumentation, Verträgen oder Plänen. Es ist eine Aussage über Prioritäten, wenn sie in Konflikt geraten. Die Frage ist nicht, ob du einen Prozess hast. Die Frage ist: Wenn dein Prozess mit dem in Konflikt gerät, was Individuen und Teams wirklich brauchen – änderst du dann den Prozess, oder übergibst du die Menschen?

Die zwölf Prinzipien, die niemand liest

Hinter den vier Leitsätzen stehen zwölf Prinzipien. Sie sind weniger bekannt als die Leitsätze – und erheblich anspruchsvoller. Einige, die besonders unbequem sind:

• Prinzip 1: „Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.” Nicht wertvolle Dokumentation. Nicht wertvolle Roadmaps. Wertvolle Software.
• Prinzip 4: „Fachleute aus dem Business und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.” Täglich. Nicht im Sprint Review. Nicht im Quartalsbericht. Täglich.
• Prinzip 5: „Errichte Projekte rund um motivierte Individuen. Gib ihnen die Umgebung und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.” Vertraue ihnen. Überwache sie nicht. Berichte nicht über ihre Velocity. Vertraue ihnen.
• Prinzip 11: „Die besten Architekturen, Anforderungen und Designs entstehen durch selbstorganisierende Teams.” Selbstorganisierend. Nicht Teams, die Aufgaben von einem Manager erhalten, der ein SAFe-Training besucht hat.

Führe den Checksum durch: Nimm Prinzip 5 – „vertraue darauf, dass sie die Aufgabe erledigen” – und halte es gegen deine aktuelle Berichtsstruktur. Wie viele Freigabeebenen braucht ein Team, um eine technische Entscheidung zu treffen? Auf wie vielen Dashboards werden Velocity und Durchsatz des Teams angezeigt? Wie viele Personen außerhalb des Teams haben Zugang zum Sprint Burndown? Die Lücke zwischen diesem Prinzip und deiner Antwort ist die Lücke zwischen Agile wie es gedacht war und Agile wie es praktiziert wird.

---

Praxisbeispiele: Die Lücke in der Praxis

Ich habe zwanzig Jahre in Enterprise-Umgebungen gearbeitet – Finanzdienstleistungen, Pharma, Energie, Automotive. Ich habe Agile auf mehr Arten eingeführt, angepasst, falsch angewendet und missbraucht gesehen, als ich zählen kann. Hier sind drei Muster, die mir in fast jeder großen Organisation begegnet sind, mit der ich gearbeitet habe.

Das umbenannte Wasserfall-Projekt

Eine große Finanzdienstleistungsorganisation beschließt, „Agile einzuführen”. Sie engagieren eine Transformationsberatung. Die Beratung liefert ein sechsmonatiges Programm, das ihre bestehenden Projektphasen in Sprints umbenennt, ihre bestehenden Projektmanager in Scrum Master und ihre bestehenden Lenkungsausschüsse in Product Owner. Die Gantt-Charts heißen jetzt Roadmaps. Die monatlichen Statusberichte heißen jetzt Sprint Reviews. Nichts daran, wie Entscheidungen getroffen werden, wie Budgets vergeben werden oder wie Teams besetzt werden, hat sich geändert. Die Transformation wird für erfolgreich erklärt. Die Probleme, die sie lösen sollte, bleiben bestehen.

Der Agile-Wrapper

Eine Pharmaunternehmen führt SAFe ein, um „Agile im gesamten Unternehmen zu skalieren”. Zwei Jahre und mehrere Millionen Euro später haben sie jedes Quartal ein Programme Increment Planning Event, das drei Tage dauert und 200 Personen umfasst. Jedes Team hat eine Velocity. Jede Velocity wird an das Management gemeldet. Jeder Manager optimiert die Velocity seines Teams statt des Werts, der für Patienten geliefert wird. Die Zeremonien laufen perfekt. Die Ergebnisse sind unverändert.

Der widerstrebende Scrum Master

Ein mittelgroßes Softwareunternehmen befördert seinen organisiertesten Entwickler in eine Scrum Master-Rolle. Man gibt ihm zwei Tage Schulung und eine Jira-Admin-Lizenz. Seine eigentliche Aufgabe – wie praktiziert, nicht wie beschrieben – besteht darin, Meetings zu planen, Menschen nach Statusupdates zu jagen und sicherzustellen, dass das Burndown-Diagramm vor dem Freitagsbericht ans Management aktualisiert wird. Er ist kompetent, gewissenhaft und zutiefst unglücklich. Er macht auch nichts von dem, wofür die Scrum Master-Rolle gedacht ist.

---

Also ist Agile tot?

Nein. Aber das Wort ist es.

Die Werte, die das Manifest beschreibt – Empirismus, Zusammenarbeit, Vertrauen, kontinuierliche Verbesserung, Wertlieferung statt Prozessfolge – sind nicht tot. Sie sind schwerer zu erreichen, als ein zweitägiger Zertifizierungskurs vermuten lässt. Sie erfordern echten organisatorischen Wandel, keine Vokabeländerung. Sie erfordern Führungskräfte, die bereit sind, Kontrolle aufzugeben, um bessere Ergebnisse zu erzielen. Sie erfordern Teams, die bereit sind, Verantwortung zu übernehmen, statt nur Anweisungen zu folgen.

Diese Dinge sind schwierig. Sie sind unbequem. Sie können nicht bei einem Anbieter gekauft oder mit einem Framework installiert werden. Und genau deshalb haben sich die meisten Organisationen für die einfachere Version entschieden – die Zeremonien ohne die Werte, die Tools ohne das Vertrauen, das Vokabular ohne die Substanz.

„Agile ist nicht tot. Aber das meiste, was unter diesem Namen verkauft, gelehrt und praktiziert wird, hat sehr wenig damit zu tun, was die siebzehn Menschen in Snowbird tatsächlich beabsichtigt haben.” Markus – agile-checksum.com

Wie echtes Agile aussieht

In zwanzig Jahren habe ich es funktionieren sehen. Nicht oft. Nicht leicht. Aber ich habe Teams gesehen, die sich wirklich selbst organisieren, Führungskräfte, die wirklich vertrauen, Organisationen, die wirklich auf Veränderungen reagieren, statt sie zu verwalten. Wenn es funktioniert, ist es nicht beeindruckend im Dashboard-Sinne. Es gibt keine Metrik, die es sauber erfasst. Was man bemerkt: Probleme werden schneller gelöst, Menschen sind ehrlicher darüber, was nicht funktioniert, und die Software, die ausgeliefert wird, entspricht tatsächlich dem, was Benutzer brauchen.

Das ist das ursprüngliche Versprechen. Es ist immer noch das Verfolgen wert. Erwarte nur nicht, dass eine Zertifizierung dich dorthin bringt.

---

Das Fazit

Dieser Blog existiert, weil die Lücke zwischen Agile wie es gedacht und Agile wie es praktiziert wird es wert ist, dokumentiert, analysiert und diskutiert zu werden. Nicht um querulantisch zu sein. Nicht um ein besseres Framework zu verkaufen. Sondern weil die Probleme, für die das Manifest geschrieben wurde – die Fehlausrichtung zwischen dem, was Organisationen bauen, und dem, was Kunden brauchen; die Verschwendung durch Prozesse, die dem Prozess statt dem Ergebnis dienen; die menschlichen Kosten, in Systemen zu arbeiten, die den Menschen darin nicht vertrauen – diese Probleme sind real und verschwinden nicht.

Der Checksum ist einfach. Nimm eine Agile-Praxis in deiner Organisation. Frage, ob sie den Werten im Manifest dient oder ihnen widerspricht. Sei ehrlich bei der Antwort. Entscheide dann, was du damit machst.

Das ist der Zweck dieses Blogs.

1. Finde eine Zeremonie in deiner Organisation, die hauptsächlich dazu dient, einen Bericht für das Management zu erstellen, statt dem Team zu helfen.
2. Frage, warum sie existiert. Frage, wem sie dient. Frage, was passieren würde, wenn du aufhören würdest, sie durchzuführen.
3. Die Antworten auf diese drei Fragen werden dir mehr über das tatsächliche Verhältnis deiner Organisation zu Agile verraten als jede Reifegradbewertung je könnte.

---

In diesem Artikel verwendete Glossarbegriffe

• Agile Manifesto – Das Dokument von 2001, das die Werte und Prinzipien der agilen Softwareentwicklung definierte.
• Cargo Cult Agile – Die Übernahme von Agile-Ritualen ohne Verständnis der zugrundeliegenden Prinzipien.
• SAFe – Scaled Agile Framework, das am weitesten verbreitete Enterprise-Skalierungsframework.
• Scrum Master – Die Scrum-Verantwortlichkeit, die dafür zuständig ist, Scrum zu etablieren und dem Team zu dienen.
• Agile Transformation – Der Prozess, durch den eine Organisation versucht, Agile-Werte und -Praktiken im großen Maßstab einzuführen.