Is Scrum dead in the AI era?

Even before AI conquered the world, I was no longer convinced by Scrum.

I started out as a database and software developer before Scrum even existed. I learned classic project management, agile, completed every kind of training and collected a vast number of certificates. I have worked as a project manager, Scrum Master, Agile Coach — the whole spectrum — always in software and data teams in very large organisations.

There are a few examples I have seen in large enterprises that genuinely worked well in terms of agility, and those teams did not use Scrum at all. Most of what I saw was unbearable, exhausting, nerve-racking.

That is just to set the tone for my personal, private opinion.

And why do I think this way?

Because the process theatre and the ticket graveyard took on absurd forms in some organisations. The waterfall-ishness, the over-coordination, how people step on each other's toes because too many roles do the same thing, how the important things simply do not get done.

It became more and more absurd, and it had nothing to do anymore with how I once worked, a long, long time ago, before agile was in the world: directly together with business colleagues, directly for users.

I think the biggest problem over the decades was that a huge wave of non-tech people flooded Scrum — people who, never having been engineers, had no personal frame of reference for what performance is actually possible, and therefore always fell back on the people topic because that was the only frame of reference they had, and in the end it is always only about:

We all sit in a circle and sing Kumbaya.

Terrible.

So: thank you, thank you, thank you, that AI is now turning everything upside down. Thank you for that. I cannot thank it enough.

The question now is: What do we do now?

I know that practically every company in the world, with very few exceptions, somehow has tickets and somehow has sprints. Some have even more, but that is the rough common ground. Roles differ in part, but everyone somehow has sprints, everyone somehow has tickets, and everyone now somehow has AI agents — or almost everyone.

And now the great chaos begins.

And I want to help sort out the chaos, because it can be done with simple means and quite differently from what most people think.

The first step you need to take is: Do not get hung up on frameworks.

Broaden your view instead.

There is this myth floating around that before Agile there was only waterfall, which is total nonsense. I have never been in a waterfall project, and as I said, I was already developing software when many of you had not even been born.

Even before Agile there were so many different ways of working and methods, and after Scrum was invented many new ones were added.

Please do not cling to some detailed playbook.

The funny thing is: the Scrum Guide already states on page 4 that Scrum is based on Lean Thinking, and nobody seriously engages with that — and that is exactly where it goes wrong.

Lean Thinking has its roots in the 1950s, when Toyota invented the Lean Production System.

Okay, now please think pragmatically.

If you are young and have never known anything other than Scrum or a modified version of Scrum, you have been trained to think that everything is somehow uniform. Always a two-week rhythm, then some have three-month milestones, then there are always some tickets, then there are always some dailies. It is always roughly the same, fine-grained, always roughly the same length and always somehow roughly the same. And that is not the real world.

Life runs in phases. It goes downhill, uphill. The seasons run in cycles. Nature has cycles. That was a huge drawback of the whole Scrum thing — please try to mentally detach yourself from this uniformity and consider that now, when AI writes code so fast and gets all sorts of other things done for you at breakneck speed, you need different sections of work that are of different lengths, look different and therefore have to be managed differently. At the same time, so that a large company does not sink into chaos, you need a certain consistency — and we will come to that in a moment.

But first of all, you have to understand the following:

1. BEFORE the coding agent is sent off, there is one section
2. Then there is the section in which the coding agent does something
3. and after that there is yet another section in which you validate the solution, measure something and learn from it

You have to embed these different sections into an organisational rhythm, and in the end that has little to do with two-week sprints.

For the sake of peace you can somehow package the whole thing into two-week sprints, but it will look completely different from your previous Scrum setup. So let go of uniformity and think in different phases.

The first phase: WHAT and HOW

The first phase is: much more brainpower now has to go into figuring out WHAT you actually want to build, then comes the consideration of HOW you want to build it, and only then do you send off the AI. These phases are currently being discussed under the terms judgement and governance. I do not necessarily have to handle these phases with Scrum and tickets. But I now have to invest much more time and thought in these phases before the AI agents get going. There are numerous helpful methods for this.

As for what you want to build, we come back to the good old classics called customer orientation, customer centricity, value proposition and whatever else they are called. All of it ancient. It was partly not done in the uniform Scrum ceremony. So back to it, do your homework: What does your customer, user or citizen actually want? You now have to put more effort into this section, because building is no longer the problem.

In this phase you of course also use AI for research or experiments or for building prototypes, but you need additional methods that Scrum never had. Here it is quite helpful to look at what Shape Up proposes, and I think you can confidently adopt ideas from it and apply them even in a huge corporation, namely the idea of asking:

What are our bets, what are our hypotheses, how much are we willing to invest in them, and at which threshold values do we stop the whole thing because our assumptions do not hold?

I was there when this was lived exactly like that in world-famous corporations. There is no argument that this cannot work in a large company. It works. You do not need a reorganisation or a change project for it. It is simply the will of leaders to do it this way.

The leaders who are sponsors, who have budget, and everyone else who carries some responsibility in that context just need to sit down together and say: Okay, from now on let us think together about which hypotheses we have, which experiments we want to use to validate them, what our bets are. Instead of just stuffing a backlog full of tickets.

Then the phase can follow in which you find out what the user, customer, citizen actually needs. After that you need people who are able to set a framework for architecture, quality and governance before you send the AI off to build it.

The build phase: freedom within tight boundaries

And the beautiful thing is: because AI can build so fast, you do not need anyone to coordinate people. Give teams the freedom to coordinate themselves by setting tight boundaries and rules of the game in advance.

When it is clear what bet you want to make, when it is clear how much funding is made available for it, when it is clear — or you have hypotheses about — what the user, customer, citizen needs, then you need a time period in which it can be built, in which domain experts and engineers with AI agents decide for themselves how often they talk and coordinate in which meetings.

Let me tell you how it used to be. I simply sat in a room for eight hours with the people who wanted something, and we did the work together. When I started as a software developer, there were no meetings. They did not exist. The culture was not there. We simply worked together. We — that was the techies and the people from the business. We sat together in a room all day and worked with each other. The word "meeting" did not even exist in Germany. In Germany there was the word "Besprechung", and Besprechungen happened roughly once a month and were deadly boring. You only went because the boss thought you had to do something like that. The actual work could be done without meetings.

And I consider returning to this way of working, where you simply work together for eight hours, very healthy — and thank you, dear AI, for leading us back to normal. Now it is called Forward Deployed Engineer, but the concept is ancient.

Because it was at times unbearable that engineers were interrupted a million times a day through every channel there is, and then, when they had five minutes in the daily to actually work together, they were cut off because the daily may only last 15 minutes. That has to stop completely. Sorry, such nonsense. Just let people do their work.

Validate, measure, learn

The period in which you test whether a bet pays off was already limited by Shape Up, which is an improvement over Scrum, because in Scrum the sprints just run on for months, on and on and on. But now with AI, perhaps even the length of a sprint is too long again.

So think about the time span you need to find out whether what was built with AI was really the right thing. Depending on what it is about for you, the period can also be very short.

It is extremely important that at the end there is always a learning — not just for one person, but for a team — and that this is carried beyond the team into the organisation.

It needs a certain cadence. When a large company has several teams and they all now work with AI agents, it needs a cadence in which learnings are exchanged across teams. That in turn can be a rhythm; whether you call it a sprint or something else does not matter. The rhythm has to fit the rhythm of the company. Ideally, the learning takes place after the whole thing has already been tested in production. Without real user, citizen or customer feedback it is worth nothing.

Such a learning also has to be digested and put to use. A learning that people only talk about, then part ways and change nothing in their further work, is completely useless. That means there has to be a phase in which the learnings change something, and on all levels: in the process, in the content, in the decisions, in the quality, in the governance. In the past this was called a continuous improvement process.

Please, please, please, please stop talking only about feelings and psychological topics. Sure, there is always potential and room to learn something there too. But that is not the main goal of work. I go to work to work. The main goal is the work.

That means the learnings have to flow into the work, and if your only learning is that you need to collaborate better, sorry, then you have not done your homework properly. Learning means: you know which assumptions were wrong, which new assumptions you can now make, what feedback the user, customer, citizen gave, what the data says, how the quality was, how the process went, whether you could have been faster and better. How was the communication?

Okay, now we are back to the people. That is part of it, but it can never take up the whole space. And if the only learning in every one of your conversations is that the leadership is not good, sorry, then we need to talk about the whole setup again. This is not "the bottom against the top" and vice versa. Collaboration is the magic word.

Roles: work instead of titles

So let us now talk about roles. I am not a fan of roles. I am a fan of finding out what work actually needs to be done and then writing down a first and last name for who does the work. Forget roles and titles. I know corporations that abolished them more than ten years ago because they simply achieve nothing.

There is so much work, the work will certainly not run out. I do not believe anyone needs to fear that there will be no more work. Quite the opposite: once you open your view, there is even more work than before. And implementing something brilliant has to be so much fun that it does not matter at all what the title is.

I also think we will constantly have to learn something new. That is why I cannot rest on any role description.

You have to be able to operate the coding agents, be able to define architecture and quality, be able to find out what should be built at all, be able to make assumptions, be able to formulate experiments, be able to define measurable KPIs, find data that can be measured and contributes to the KPIs, create the conditions so that people can work in peace, and, and, and, and, and. So much work.

Write down all the activities.

Then: all developers, business analysts, engineers, Scrum Masters, Product Owners, team leads, leaders X, Y, Z — who knows how many leaders you have and what they are all called. Just write down their first and last names.

You have the list of activities and then you match: Who does what? And that does not have to be set in stone; it can change every now and then.

And after a few months you might come up with new role names, or you learn as an organisation and say: it blurs anyway. It blurs. Never mind. We work together. You are welcome to keep the role title in your employment contract, nobody is taking it away from you, but in daily work the work simply has to get done, and all work is valuable, and in every piece of work I have to learn, and we all start learning somewhere, and nobody knows everything. So relax.

I have seen it too often, live and in colour. People are afraid. People have too much to do. People have too little to do. Everyone develops their own strategy to somehow get through life. And that creates completely unnecessary, stupid things.

I have seen people set up meetings only because they do not know what else to do. That is why it is so important that you invest a few days and simply find out what work needs to be done and who does this work. It will feel like a liberation.

There are people who are genuinely afraid. They are completely unsettled. They want to give their best and do not know where and how. And they would never tell you, and they will never show it either.

Through my life experience — I am a little older — I now have quite a good feel for it, and how often I have seen what enormous relief arises when someone takes this in hand in such a way that nobody loses face.

Stay relaxed. Do not make a big drama out of it. Do not turn it into a doctoral thesis. Simply write down the work that needs to be done, the names next to it, and that is it.

Tickets, backlog and real performance

Whether you still use tickets or not depends a bit on how you set things up with the AI agents. For what people prepare and follow up in phases, I would say some wiki page with a basic table is enough. I think the days of maintaining fine-grained tickets are over.

And to be honest, a backlog full of things that never get finished was always mega, mega un-agile, because Lean Thinking — the root of agile from the 1950s — knows eight types of waste, Muda, and tickets in the backlog are a great example of waste.

Use the opportunity to rethink the whole of Scrum and to focus on performance again. Not performance in the sense of: we hit milestones, we produce lots of tickets, we review like crazy what the AI agents do — but performance in the sense of: the customer loved what we did. We earn much more money, we save costs, we win more customers, we conquer new markets. Performance criteria like that, and very importantly: we learn.

The moment you do something great, earn a lot of money and do not learn, you are building legacy. Use the opportunity for a fresh start.

For every business problem that is now unsettled by Scrum and AI, I could show you pragmatic tips and solutions for getting out of it without a massive reorganisation or change projects. For that I need to know what you are working on right now. Contact me. I am also currently writing a playbook so that you can do this without bringing expensive management consultants into the house. I look forward to your feedback.

FAQs

Do we still need Scrum at all?

1. Does Scrum still work with AI agents?

You read on social media about AI engineers who have built a Scrum team out of AI agents. That works, but this answer does not help you in a larger organisation.

I think it is like this: Scrum, as you know it, will not work for much longer. It also depends on how advanced your software development with AI agents is.

The change will happen in phases.

First of all, it certainly makes sense to have some kind of cadence. If the whole organisation thinks and works in sprints, you can leave it that way for now, but use them differently.

The team composition, however, will no longer work. Neither will the fine-grained tickets. The roles will change. The review will be blown apart — who is supposed to review everything that AI creates so quickly? Deciding what is built at all and how will take more time, but during that time you cannot develop, so different rhythms emerge within a team.

The leadership structures around the Scrum teams will have to change if you left them untouched back when Scrum was introduced. The more you work with AI agents, the more you will notice that Scrum reaches its limits, inside and outside the Scrum team.

2. Does Scrum still make sense when AI agents can develop faster than humans?

My personal opinion: No. There are better ways to structure and organise the new way of working. The large organisations in which I worked during the agile transformation gave teams the freedom to use Scrum or not, and the real change took place in the leadership structures and in the way initiatives are carried out. Even before AI, Scrum did not fit everything. When the AI agents work, you do not have to wait 2 weeks, and nobody can review the amount that is produced.

Nevertheless, there has to be a way to decide: what is worth building? How do we validate it? What is our feedback loop? What does the user/customer/citizen say about our solution? How much budget is it worth? How do we do governance?

Scrum never fully answered any of these questions anyway. That is why some organisations used additional methods even before AI, and some organisations merely mapped Scrum as waterfall in tickets. If the latter is closer to how it is lived in your organisation, Scrum no longer makes sense with AI agents. Then it makes much more sense to first look at the flight level above: on what basis do we decide what gets done, how do we validate it, what are our feedback loops, do we have kill criteria, and what does the customer/user/citizen say about it?

3. Do we still need sprints when AI agents can work 24/7?

Not for the agents. But you need different rhythms for the people in the organisation. You need a rhythm in which it is decided what gets built, one for feedback loops, one for governance decisions, one for learning in the organisation, one for changes of direction, one for budget decisions and so on. These rhythms have to be brought into a common cadence. Whether you keep using the word sprint or not is secondary. But the different rhythms can by no means all be 2 weeks long. Some will be shorter and some will be longer. These 2-week sprints also had a huge drawback. Humans and nature work in cycles. AI brings you back to working in cycles, which is great progress. You have to plan time in which it is decided what is built and how, then the AI builds it fairly quickly, and perhaps you were wrong and you discard it again. You now have the freedom to choose the time periods for this yourself. That makes work enormously easier, because not all these activities are the same and they no longer have to be squeezed into identical tickets and identical sprints. Seize this opportunity!

4. Is Agile obsolete because of AI agents?

Quite the opposite. The agile values are timeless. But honestly, one has to say that Agile as a term is truly no longer bearable. And just let the topic rest. Nobody can stand hearing it anymore.

It is better to become concrete, to offer concrete practical help. Lean Thinking helps much more there.

Take, for example, the 8 types of Muda, waste. The moment you work with AI agents, you scale waste if it was already there before. So it makes a lot of sense to engage with it.

Or take work-in-progress limits from Kanban. If dozens of AI agents now work in parallel and you do not consciously limit that, you limit the lead time, because there is always a bottleneck somewhere. A shorter lead time means you wait longer for the return on investment. That can even be calculated mathematically.

"Avoid unnecessary mistakes" is another helpful principle from the Lean philosophy that is now becoming extremely important with AI agents. Before the AI agent automates something, you have to think the use case through carefully, otherwise you scale avoidable mistakes and could embarrass yourself.

These are just a few examples. Agile was derived from Lean. Lean has existed since the 1950s. I therefore recommend going back to the roots, recombining them with today's knowledge and then applying them concretely to working with AI agents.

Rethinking Scrum vs. replacing it completely

5. What is the best alternative to Scrum for AI-native teams?

Scrum was introduced worldwide, whether it fit or not. Most of the time it was not really Scrum at all. If you now have AI-native teams, several factors matter before you decide which way of working is best for you. You definitely need direct collaboration between users/customers/citizens — or someone who represents this group — and the AI engineers. You need a feedback loop. You need criteria by which you decide whether and how something is built and why something is discarded again. You need governance. The smaller teams can organise themselves but must be included in the points just mentioned. I recommend engaging with Lean Thinking and with Kanban. Shape Up also has helpful elements. What matters is that you change the way of working so that it fits your initiative.

6. Scrum vs. Shape Up — which is better for AI-assisted development?

Shape Up has valuable elements that help people decide what should be built at all. Once that is clear and the AI agents are working, the AI agents can use a kind of Scrum. Scrum reaches its limits when you combine AI agents with humans, because no human can review the volume, and the AI agents do not need a human Scrum Master either. But they need to know what should be built and how, and Shape Up offers helpful elements for that. See also this article: Shape Up vs. Scrum — an improvement from my perspective

7. Is Kanban better than Scrum for teams with AI agents?

Kanban has one big advantage: work is limited. Work-in-progress limits, also called WIP limits. That is helpful for teams working with AI agents. On the one hand you limit the work the AI agents do, because otherwise you overload the people steering them, and on the other hand you limit work one flight level higher, namely how many projects or initiatives are worked on simultaneously in one or more teams at all.

Kanban has no prescribed meetings or events. That gives teams the freedom to design this themselves.

Kanban measures how long it takes from the idea to productive use; this is called lead time. And Kanban measures how long it takes from the moment work on the idea begins until productive use; this is called cycle time.

When working with AI agents, these are more meaningful metrics than tickets per sprint or story points (although story points were never intended for measurement — more on that below).

Kanban helps you think and work in a more outcome- and impact-oriented way. That is why, in my opinion, it is better for teams that are already very advanced in working with AI agents.

However, this requires that the leadership team understands Kanban and also lives it at the higher flight levels. Here I recommend engaging with the Flight Levels of Dr. Klaus Leopold.

Measuring and planning vs. just doing

8. Do story points still make sense with AI agents?

No. Clearly no. Story points are a sensitive topic; there is a lot of argument about them. I do not want to reopen the old discussions. Just this much: a well-attuned team at some point only has 5 or 8 story points per ticket, because they have managed to slice work packages evenly small, understand them well, and because the shared way of working is aligned. And if everything has the same number anyway, you might as well leave it out.

Now with AI agents it is extremely important to measure OUTCOME. By that I mean: what added value for the customer/user/citizen does what was just built have? You urgently need to stop measuring the number and duration of work packages. Heed this advice! If AI agents build very fast and very much and none of it ultimately delivers measurable value to the company, then you may impress with an excellent measurement, but you miss the actual goal!

So what is the most important consideration on the topic of story points, estimates and measurements? How do we measure the value of what is being built here? For that you need suitable KPIs and NOT story points.

9. Do we still need velocity at all?

I ask you: what significance does the speed of a team made up of people who use AI agents have if what the team builds delivers no value to the company?

AI is mega fast. Why measure that? People are the bottlenecks.

It certainly makes sense to measure where processes slow down and get congested. But for that I do not use velocity as a metric, but other KPIs, such as how long it takes from the idea to the point at which the solution is productively usable for customers/users/citizens.

This measures how quickly you as an organisation can implement something. That is an important measurement. How quickly a team builds something is only a small part, because before the team starts and after the team is finished, things may happen outside the team, and these must be included in the measurement.

Rule of thumb: In the age of AI agents, measure outcome-oriented along the entire process chain and stop measuring the activity of individual steps.

10. How do you measure team productivity when developers work with AI agents?

It is pointless to measure team productivity. It is a vanity metric. It may give you a reassuring feeling, but by measuring team productivity you contribute in no way to business success. All the smart teams in the world know how to behave in order to increase such pointless metrics. By measuring team productivity you open a pointless game that you can never win.

Start learning how to use business KPIs to measure whether what developers do with AI agents contributes to the company's goals at all.

I say this so bluntly because this question reveals that you urgently need to rethink.

Engineers are clever people. Whatever productivity measurement you want to do, the engineers will impress you with numbers.

But if what is being built is not at all what the company needs, what use is a mega-productive team?

Or if things move incredibly slowly before the work reaches the team or after the work leaves the team, what use is it then?

Or if the team has many dependencies in which nothing changes and which slow the team down, what does the measurement say then?

Or if at a certain point in time it made sense to build what was built, but some time later it no longer makes sense because the world has moved on, what does the confirmation of how productive everyone was help you then?

NOTHING!

It certainly makes sense to measure where processes slow down and get congested. But for that I do not use velocity as a metric, but other KPIs, such as how long it takes from the idea to the point at which the solution is productively usable for customers/users/citizens.

There are technical KPIs such as deployment frequency, change failure rate or number of bugs. These make sense when business value is measured via KPIs at the same time.

11. Does estimation still make sense with AI?

Not at ticket level. At a higher flight level, yes. If several teams in your organisation are working on a larger initiative, it certainly makes sense to use some kind of estimate to understand when and how the individual parts come together into a whole.

Processes and ceremonies vs. speed

12. Which Scrum ceremonies still make sense with AI agents? Do we still need daily standups when AI agents do a large part of the work?

The AI agents can do Scrum among themselves. But they then do all the Scrum events of a sprint in one day.

The people in a team should keep the Scrum events they need, because people who work together still need to talk to each other every day. What matters here, however, is flexibility regarding the agenda. I recommend letting the team decide for itself which agenda helps most for each Scrum event right now, because that changes. The better you build the overall setup of the AI agents, the less people need to dive into the details.

13. Do we still need sprint planning with AI agents?

My computer science professor at university always said: Planning is the replacement of chance by error. Planning means someone has a plan. That means someone assumes the plan is good. Assuming that a plan is good is naive.

A mature approach is this: I make assumptions and think about how I can validate or refute them. Which experiments can I run and how do I measure that?

With AI agents you should start working hypothesis-driven. The AI agents work incredibly fast. They can carry out the validations quickly.

Planning then only has the function of making sure that people understand what the AI agents will do next and that the AI agents receive the written instructions for it.

It can run completely differently from a Scrum planning.

The AI agents then break the tasks down into subtasks among themselves and may also carry out a kind of planning here.

What matters is that before people start the AI agents, you are clear about which assumptions you have made and how you want to measure whether you were right or wrong.

14. Do we still need retrospectives when part of the team consists of AI agents?

You need a regular event in which you receive feedback from customers/users/citizens on your solution.

You need a regular event in which you understand and capture the learnings of individuals and teams and translate what you have learned into changes to the solution, the approach, the structure, the system and so on.

You need a regular event in which you discuss what the measurements of business- and outcome-oriented KPIs mean for the solution and for the work of the teams and AI agents.

What you call this event does not matter. It must take place regularly, work through these points with discipline, and be able to actually implement what was discussed.

You can of course also talk about feelings and psychological safety — but if that makes up the main part of a retrospective for you, your overarching setup is not yet mature. Talking mainly about feelings in a retrospective is a signal that the leadership team has not yet understood how to set up the AI Operating Model so that the teams' work with AI agents contributes to business value.

15. Do we still need Jira with AI agents?

Jira, Azure DevOps or similar tools have various functions. It is not only about the tickets in the sprint. You can use them to plan across sprints, and to coordinate and plan across teams. You can use them for test management. Jira and Azure DevOps are also tools that can map fully automated pipelines of a complete DevOps process across different environments (or provide the integrations for it).

When you work with AI agents, the question arises which functions of Jira are still necessary and which fall away. In my opinion, abstraction levels across teams and sprints remain important. So does a functioning test and DevOps structure. You also need some kind of written collection of the things the AI agents are supposed to do. These can be tickets. But it can also be solved differently. It depends very much on your own organisation and on the degree of autonomy your AI agents have, which in turn depends on how well you have already prepared architecture and governance.