Das Label "Agile" ist verbrannt. Agiles Arbeiten als Handwerk fängt gerade erst an.

Wenn das Label "Agile" so viel Ballast mit sich herumschleppt, dass es die Lösung verhindert, müssen wir es loslassen. 2026 beenden wir das Agile Theater und fangen wieder an zu bauen.

Die Asche des Hypes – Warum das Label am Ende ist

Die Erschöpfung rund um das Thema "Agile" ist überall zu spüren. Sei es in sozialen Netzen, in Teams und auch in Unternehmen. Das liegt vor allem daran, dass "Agil" zum Container für alles und jedes wurde – vom Micromanagement unter neuem Namen bis zur reinen Selbstbeschäftigung der „Methoden-Hüter“.

Die Konsequenz: Wer 2026 noch „Agilität einführen“ will, erzeugt keine Aufbruchstimmung mehr, sondern nur noch Abwehrreaktionen. 

Warum ich schon immer von „agilem Arbeiten“ spreche

Einigen ist es schon ganz am Anfang aufgefallen. Ich sage nicht Agilität, ich sage agiles Arbeiten. Diese Worte habe ich bewußt gewählt - hier im Blog, im Podcast und auch im Buch. 

Agilität ist ein (mittlerweile verbranntes) Substantiv, das nach einem statischen Zielzustand klingt. Das ist vom Ansatz her schon falsch. Agilität ist auch kein Ziel, es ist ein Mittel, ein Ziel zu erreichen. 

Agiles Arbeiten beschreibt daher viel besser, worum es gehen sollte: Wir arbeiten agil, weil wir ein Ziel erreichen wollen. Das Ziel ist in einem komplexen Umfeld gute Software schnell zu liefern. Wir wollen Werte und keinen Waste schaffen. Dafür gibt es nur eine Herangehensweise: Iteration und Feedback. Und das ist harte Arbeit. Übrigens: mehr ist agiles Arbeiten auch nicht. Iteration und Feedback. 

Die Logik des Systems – Warum Frameworks die Arbeit oft verhindern

Es gab letztens eine schöne Umfrage auf Mastodon von Marco von SCRUMschau.

80% aller Teilnehmer haben entweder keine Ahnung, warum sie Scrum machen oder sagen klar, dass es von oben vorgegeben ist. Und wie ist das Management wohl auf Scrum gekommen? Wollten sie wirklich mehr Wert schaffen und hatten sie wirklich die Chance zu verstehen, ob Scrum ihnen dabei hilft?

In so einem Umfeld brauchen wir nicht darüber reden, welches wohl das bessere Framework ist - der Drops ist gelutscht. Alle werden diese Diskussion ablehnen. Das Thema wird als Fremdkörper verstanden. Kein Wunder, dass ich heute auf LinkedIn als Lösung zu einer Frage von mir nicht nur einmal gelesen habe, dass mehrere nach neuen Begriffen, Methoden oder Frameworks verlangen. 

Das ist nicht der Weg. Es ist klar absehbar, dass das alles nur alter Wein in neuen Schläuchen sein wird. Die neuen Begriffe, Methoden und Frameworks werden auch alle verbrennen.

Der Glaube, dass man durch das Ändern von Rollentiteln und die Einführung eines regelmäßigen Zusammenstehens mehr Wert schafft, klingt absurd. Der Ausweg: Keine Missionierung sondern eine ehrliche Nutzen-Diskussion. Wir hören auf, die Leute zu „agilen Gläubigen“ zu erziehen, und fangen an, ihre echten Painpoints im Handwerk zu lösen.

Handwerk - agiles Arbeiten. Ich bin mit dieser Sicht nicht allein. Ansätze wie die ‚Agile Primitives‘ von Stefan Wolpers zeigen genau in diese Richtung: Weg von komplexen Regelwerken, zurück zu den fundamentalen Bausteinen, die Zusammenarbeit wirksam machen. Es geht nicht um den Erfolg eines Frameworks, sondern um den Erfolg der Arbeit.

Wenn wir über Painpoints sprechen, sollten wir auch so ehrlich sein und sagen, dass agiles Arbeiten erst einmal ein Overhead ist. Die Rituale, das Verbreiten des Mindset, das Kleinschneiden von Anforderungen, die Feedback-Zyklen. Alles Overhead und teuer. Daher gehört es in einer Painpoint-Analyse dazu, genau zu schauen, ob die Arbeit überhaupt all das braucht. 

Das vergessen nämlich leider sehr viele Menschen. Es gibt Arbeit, die muss nicht agil umgesetzt werden. Ist sie einfach genug, um sehr genau vorherzusagen, was rauskommen soll und wie es umgesetzt werden soll. In so einem Szenario brauchen wir "agile" nicht. Repetitive Tätigkeit. Warum sollte man dann noch etwas darüber stülpen, dass für ganz andere Situationen gedacht und teuer ist?

Der Entwickler als Architekt – Handwerk schlägt Ticket-Schubsen

Entwickler haben das Theater am schnellsten durchschaut. Sie sind schon lange frustriert. Sie wollen schon lange "einfach nur arbeiten". Sie sind müde. Ihr Motivator ist es, Software in guter Qualität zu liefern, die einen Zweck erfüllt und benutzt wird.

Warum kollidiert das dann mit der "agilen" Realität? Weil wir in den meisten Unternehmen nicht über agiles Arbeiten reden. Ihnen wurden Methoden und Frameworks verkauft, egal ob sie passten oder nicht.

In der Theorie, ganz nüchtern betrachtet, sollte aber agiles Arbeiten und die oben beschriebene Motivation von Devs zusammenpassen. Agiles Arbeiten ohne Architektur-Verständnis, Clean Code, Test-Automatisierung und Feedback - also all das, was wir auch unter technischer Exzellenz verstehen - führt nur dazu, dass wir „schneller im Kreis laufen“. Damit verbessern wir uns nicht. Und daran scheitern Implementierungen von agilem Arbeiten in Unternehmen heute.

Ich bin sicher: Die neue Währung in 2026 wird technisches Urteilsvermögen. Es wird um das Handwerk gehen. Es wird immer weniger darum gehen, in Jira ein Ticket zu schubsen oder jeden Tag morgens einmal zusammen zu stehen.

Es gibt noch eine weitere Entwicklung, die das unterstützen wird.

KI als der gnadenloser Bullshit-Filter

"KI" ist ein sehr weiter Begriff, daher muss ich etwas trennschärfer werden. Ich rede hier vor allem vom Einsatz von LLMs in der Entwicklung. Ich denke, nach drei Jahren öffentlicher LLMs sehen wir klar. Für mich hat sich in dem Bereich in 2025 auch wenig getan - vor allem, wenn ich das mit 2023 oder 2024 vergleiche. Es ist klar, was LLMs können und was sie nicht können. Natürlich ist das Ökosystem um LLMs weiter gewachsen (Agenten, MCP, CLIs, ...). Aber alles basiert auf einem Sprachmodell. Und diese Technologie hat sich eben nicht deutlich verändert in 2025. 

Zeit also zu schauen wo wir stehen und wo die Reise hin geht. Es ist klar, dass der richtige Einsatz von LLMs ein Einsparpotential besitzt. Ich spreche hier von One Shot Prototypen die in den Müll wandern können, komplexerer Code Completion oder Scannen von Code auf Qualität, Security und Performance. Hier steckt ein Potential und wir alle nutzen es.

Es ist auch klar, dass der Traum einiger, zumindest Juniors nicht mehr zu brauchen und damit Personalkosten zu sparen, nicht "in Erfüllung" geht. Es gibt sehr viele Beispiele, in denen Unternehmen, die diesen Weg versucht haben, zurückrudern. Das ist die logische Konsequenz. Wir können Juniors nicht ersetzen. Sie sind die Seniors der Zukunft. Oder woher sollen sonst die Architekten unserer Software in Zukunft kommen? Ebenso sind LLMs nicht in der Lage, Seniors zu ersetzen, da sie permanente Kontrolle benötigen.

Was viele noch gar nicht in der Diskussion bedenken: Heute kosten API Calls an LLMs ein paar Cent. Es ist aber offensichtlich, dass das nicht kostendeckend ist. Auch klar ist, dass der Zeitpunkt kommen wird, wo Investoren etwas von ihrem investierten Geld sehen wollen. Das wird dazu führen, dass die Anbieter von LLMs die Preise erhöhen, denn Werbung im Code ist wohl keine Alternative. Und wenn dann das monatliche Budget für LLMs statt €2.000 in Richtung €10.000 geht, ist der Weg nicht weit, einen Menschen einzustellen, der wirklich intelligent ist.

Bei dem, was dann von der LLM-Nutzung übrig bleibt, sind die Prinzipien des agilen Arbeitens perfekt geeignet, dies zu integrieren. Prototyping, Testing, Code Completion - alles Technologien, die wir für unsere schnellen Feedback-Zyklen brauchen. 

2026 – Die Rückkehr zur ökonomischen Vernunft

Ich prophezeie, dass 2026 für das echte agile Arbeiten ein tolles Jahr wird. Aber eben nur für dieses echte Arbeiten - nicht für das unreflektierte Einsetzen von Frameworks oder das Consulting, dass die immer gleiche Methodik einführt. Auch das Erfinden von neuen Frameworks oder die Einführung neuer Namen wird keinen retten.

In 2026 sehen wir das Ende der „Glaubenskriege“ (Scrum vs. Kanban vs. SAFe). Unternehmen fordern wieder operative Wirksamkeit und Ergebnisse in kurzen Zyklen.

Gut so!

Die logische Konsequenz: Weg vom Zeremonienmeister, hin zum Ermöglicher, der Hindernisse im Wertstrom erkennt und beseitigt. Das Label ist tot. Die Arbeit beginnt.

Willkommen in der Werkstatt des agilen Arbeitens.