The "Agile" label is burnt. Agile work as a craft is just getting started.

If the label "Agile" carries so much baggage that it prevents solutions, then we have to let it go. In 2026, we end Agile theater and start building again.

The Ashes of the Hype – Why the Label Is Finished

Exhaustion around the topic of "Agile" is everywhere. Be it in social networks, in teams, or in companies. This is primarily because "Agile" has become a container for anything and everything – from micromanagement under a new name to the pure self-occupation of the "method guardians".

The consequence: Anyone still wanting to "introduce agility" in 2026 no longer creates a sense of momentum, but only defensive reactions.

Why I Have Always Spoken of "Agile Work"

Some noticed it right at the beginning. I don't say agility; I say agile work. I chose these words deliberately – here on the blog, in the podcast, and also in the book.

Agility is a (now burnt) noun that sounds like a static target state. That approach is wrong from the start. Agility is also not a goal; it is a means to achieve a goal.

Agile work therefore describes much better what it should actually be about: We work in an agile way because we want to achieve a goal. The goal is to deliver good software quickly in a complex environment. We want to create value, not waste. There is only one approach to that: iteration and feedback. And that is hard work. By the way: agile work is nothing more than that. Iteration and feedback.

The Logic of the System – Why Frameworks Often Prevent the Work

There was a great poll on Mastodon recently by Marco from SCRUMschau.

80% of all participants either have no idea why they are doing Scrum or clearly say that it was mandated from above. And how did management come up with Scrum anyway? Did they really want to create more value, and did they really have the chance to understand whether Scrum would help them do that?

In such an environment, we don't need to talk about which framework might be better – that ship has sailed. Everyone will reject this discussion. The topic is perceived as a foreign body. No wonder that today on LinkedIn, as a solution to a question of mine, I read more than once that several people are calling for new terms, methods, or frameworks.

That is not the way. It is clearly foreseeable that all of this will just be old wine in new bottles. The new terms, methods, and frameworks will all burn just the same.

The belief that you create more value by changing role titles and introducing regular stand-ups sounds absurd. The way out: no missionary work, but an honest discussion about benefits. We stop educating people to become "agile believers" and start solving their real pain points in the craft.

Craft - agile work. I am not alone with this view. Approaches like the ‘Agile Primitives’ by Stefan Wolpers point exactly in this direction: away from complex rulebooks, back to the fundamental building blocks that make collaboration effective. It’s not about the success of a framework, but about the success of the work.

When we talk about pain points, we should also be honest enough to say that agile work is first and foremost an overhead. The rituals, spreading the mindset, slicing requirements, the feedback cycles. All overhead and expensive. Therefore, a pain point analysis must also take a close look at whether the work even needs all of this.

Unfortunately, many people forget that. There is work that does not need to be implemented in an agile way. If it is simple enough to predict very precisely what the outcome should be and how it should be implemented, then we don't need "agile." Repetitive tasks. Why put something on top of it that was designed for completely different situations and is expensive?

The Developer as Architect – Craft Beats Ticket Shuffling

Developers saw through the theater the fastest. They have been frustrated for a long time. They have long wanted to "just work." They are tired. Their motivator is to deliver software in good quality that serves a purpose and is actually used.

So why does that collide with "agile" reality? Because in most companies, we are not talking about agile work. Methods and frameworks were sold to them, whether they fit or not.

In theory, viewed soberly, agile work and the motivation of devs described above should go together. Agile work without architectural understanding, clean code, test automation, and feedback – in other words, everything we also understand as technical excellence – only leads to us "running in circles faster." That doesn't improve anything. And that is exactly where implementations of agile work in companies fail today.

I am convinced: the new currency in 2026 will be technical judgment. It will be about the craft. It will be less and less about pushing tickets in Jira or standing together every morning.

There is another development that will support this.

AI as the Merciless Bullshit Filter

"AI" is a very broad term, so I need to be more precise. I am primarily talking here about the use of LLMs in development. I think after three years of public LLMs, we see things clearly. For me, little has changed in this area in 2025 – especially when I compare it with 2023 or 2024. It is clear what LLMs can do and what they cannot do. Of course, the ecosystem around LLMs has continued to grow (agents, MCP, CLIs, ...). But everything is based on a language model. And that technology simply did not change significantly in 2025.

So it's time to look at where we stand and where the journey is heading. It is clear that the correct use of LLMs has cost-saving potential. I am talking about one-shot prototypes that can be thrown away, more advanced code completion, or scanning code for quality, security, and performance. There is potential here, and we all use it.

It is also clear that the dream of some – at least no longer needing juniors and thus saving personnel costs – is not "coming true." There are many examples of companies that tried this path and then backed off. That is the logical consequence. We cannot replace juniors. They are the seniors of the future. Otherwise, where are the architects of our software supposed to come from? Likewise, LLMs are not able to replace seniors because they require constant supervision.

What many people don't even consider in the discussion yet: today, API calls to LLMs cost a few cents. But it is obvious that this is not cost-covering. It is also clear that the time will come when investors want to see a return on their invested money. This will lead LLM providers to raise prices, because ads in code are hardly an alternative. And when the monthly budget for LLMs moves from €2,000 toward €10,000, the step to hiring a human who is actually intelligent is not far.

For what then remains of LLM usage, the principles of agile work are perfectly suited to integrate it. Prototyping, testing, code completion – all technologies we need for our fast feedback cycles.

2026 – The Return to Economic Reason

I predict that 2026 will be a great year for real agile work. But only for this real work – not for the unreflected use of frameworks or the consulting that introduces the same methodology over and over again. Inventing new frameworks or introducing new names will not save anyone either.

In 2026, we will see the end of the "wars of belief" (Scrum vs. Kanban vs. SAFe). Companies will once again demand operational effectiveness and results in short cycles.

Good!

The logical consequence: away from the master of ceremonies, toward the enabler who recognizes and removes obstacles in the value stream. The label is dead. The work begins.

Welcome to the workshop of agile work.