Scrum isn't dead at all

This article was originally written in Dutch.

‍

My LinkedIn feed is certain: agile is dead, Scrum is dead, and the Product Owner can pack up their things, because AI takes it from here. It sounds good. It fits the feeling that everything is upside down.

Last week I took part in a hackathon. A team of people, each with a set of agents, half a day, build a product. No process handbook, no ceremony, no board with columns. What stood out was that we started with a plan and a goal anyway. A list of to-dos that each of us pulled work from. Every so often we showed what we’d made. And at the end we looked back on how we’d worked together.

Nobody said “Scrum”. We just did it, because under pressure it’s the first thing you reach for. Not because it’s in a guide. Because it’s practical.

The words die, the principles don’t

That’s the misunderstanding behind all those tombstones on LinkedIn. What dies are the words and the rituals: the mandatory card-shuffling, the ceremony for the ceremony’s sake, the fourteen days called “a sprint” because that’s simply how it’s done. Let’s be honest: that’s the Scrum that expensive consultants came to impose — the rituals dutifully ticked off, and dropped precisely where they hurt. No wonder the word became tainted for so many. Good that it’s disappearing. Underneath those words sits only a small number of principles that have nothing to do with fashion, and everything to do with how people get something done together.

Start with a shared picture of what you’re making. Cut it into pieces and work from the top down. Merge regularly and check that it works. Show it to real users. Look back on how you did it. That’s not a methodology; it’s common sense that happens to have been given a name.

And precisely now that the agents are taking over the typing, those principles don’t become less important. They become more important. Because as I wrote in an earlier post, typing speed disappears as the natural brake — and then you need something else to keep you aligned. That, really, is what this is about.

Start with a shared picture, or build the wrong thing with conviction

It took us a while to get going, and that wasn’t down to the technology. It took time to reach a shared picture of the problem we were solving. Who are we building this for? What matters to that user? What does that look like, then?

Annoying, that delay — until you consider the alternative. Without that clarity, four people and an army of agents would have built four different products at breakneck speed. The onboarding, for instance, looked entirely different once we agreed on who walks through it. Had that picture not existed, we’d have built the wrong thing with plenty of energy and conviction (and faster than ever). It’s exactly what my colleague Michiel Kooiman calls automating your assumptions: with AI you just bake your wrong assumptions in faster.

This is the work no agent does for you. A model builds what you ask; it doesn’t decide whether it’s worth building. That judgment — what do we want, for whom, and why this and not that — is where the value sits. It’s the foundation everything else rests on.

The Product Owner isn’t dead — they’ve become a developer

So no, the role that guards that picture doesn’t disappear. It changes shape.

After the first phase, you saw that hat rotate. Because we were all building the same thing, now one person, then another picked up the task of keeping the separate parts fitting together — not with power or a mandate, but with dialogue and examples. It was no longer a separate functionary shouting priorities from a distance. It was someone who built along, thought about the technical side, and steered on coherence as they went. And the reason that hat could rotate without descending into chaos was the shared picture from the first phase: once the goal is sharp and shared, nobody has to enforce direction by authority. The vision guards itself.

Often with no more than a few words. “That’s nice, more of that.” And: “This I’m not sure about yet.” That last one is enough to set the agents to work on a different variant. Because building costs almost nothing now, so the most expensive thing you can do is build the wrong things, neatly and fast.

And that’s what bothers me about the claim “we don’t need a Product Owner anymore”. The opposite is true. When building was the bottleneck, you could afford a weak product judgment; it all took time anyway. Now that building is cheap, that judgment — what’s valuable, what isn’t — becomes exactly the scarce good. You don’t need that role less. You need it more than ever.

Who guards how you work together?

There was also a role we let slide: that of the person who watches not the content, but the collaboration itself. Partly because of the short time, though it remained noticeable.

There was plenty of contact and short demos, so we weren’t entirely blind. Only: “I’m stuck” stayed a statement, not a cue to help. And nobody guarded the regular merging — continuous integration (Kent Beck wrote it down in 1999 in Extreme Programming Explained, so the idea is a good quarter-century old). And when your sprint has shrunk to a single day, “merge at the end” isn’t an option at all anymore.

The teams that did reach a product organized that guarding. Pairing in twos ran rough; a team that all sat around one screen together (mob programming) held one rhythm by default. And the teams that agreed up front where their parts meet (interface-first) had noticeably less noise between the developers.

The pattern is always the same: where someone guarded how the work came together, it came together. Where nobody did, it drifted apart — amicably, and at high speed.

Agree on what “good” means

One agreement we missed entirely: what does “done” mean? There was no shared bar for quality. And that’s exactly why the seniors said at the end: nice for the demo, but we’d never push this to production like this.

Here lies a surprisingly simple win, and at once a new habit for the age of agents. Write one small file — call it quality.md — in which you agree what quality means for this product and how you demonstrate it. You share it with your team members, so everyone holds the same bar. But you also give it to your agents, which then test against it themselves. One document that keeps people aligned and steers machines.

And it fits nicely with the other small files you use to keep a grip on your agents: the role and boundaries you set down, the intent you determine up front. Small, readable agreements, shared by human and machine.

Scrum is dead. And this is what works.

Do you find “Scrum” a tainted word? Throw it out. Then do this:

1. Start with a shared picture of the problem — for whom, and what matters. Appoint someone, if need be, to formulate that sharply and guard it.
2. Make a list of what you want to do and share it. Work from the top down: the most important first.
3. Work each day toward one concrete goal — and get it finished. Don’t do everything at once; actually complete things before you start something new.
4. Agree on what “good” means and how you demonstrate it. A list of quality requirements, shared with your people and your agents.
5. Merge regularly and check that it works. The working whole is your proof, not the separate pieces.
6. Show it to real users every so often and ask whether this is what they expect.
7. Look out for each other and the collaboration — and look back on it periodically to make it better.

It probably sounds familiar.

The bottom line

What dies isn’t Scrum. It’s the caricature of it: process as ritual, agile as a checklist. Good riddance to that. The core stays standing — a shared goal, work in manageable pieces, merging regularly, showing users, reflecting on how you work together. That’s not a relic from the era of slow teams. It’s the scaffolding you need precisely now.

Because the agents have taken away one thing: building is no longer the hard part. And everything that surfaces as a result — knowing what you want, reaching agreement, guarding that it comes together, agreeing when it’s good enough — is exactly what Scrum was always about.

The Product Owner hasn’t become obsolete. They’ve become indispensable: now that building costs almost nothing, the most expensive mistake you can make is building the wrong things — and deciding what is worth it is something no agent does for you. And that process your timeline says is dead? You were doing it last week, without realizing.

‍