The Question I Get Asked Most Since Leaving Scrum.org: "What comes after Scrum"

Since leaving Scrum.org, I get asked one question more than any other. I was initially surprised that it isn't "what are you doing next", but instead it's "so, what comes after Scrum"

It usually comes with a grin. I think people want to see whether the person who spent over ten years running Scrum.org will finally crack and admit it's time to move on. I've gotten quite good at buying myself a few seconds with a sip of tea :-)

I get why people are asking though. The teams I talk to are seeing the same things. Pull requests are bigger and arriving faster. The review queue is growing while the coding queue shrinks. Someone finishes in an afternoon what the team sized at a week, and then the team spends a couple of days working out what it broke. And Sprint Planning has started to feel a bit like guesswork, because nobody is quite sure what "capacity" means anymore.

So it's a fair question, but I don't think it's quite the right question. What I want to know is what Scrum was meant to do in the first place, and what it looks like now that building isn't the hardest bit. That's a lot of what I'll be working on at Value Amplified.

Building got cheap. Judgment didn't.

Dr Alan Brown and I have been chewing on this for a while now. One idea we kept coming back to comes from Ajay Agrawal, Joshua Gans, and Avi Goldfarb's book Prediction Machines. They describe AI as a drop in the cost of prediction, which sounds a bit abstract until you apply it to a product team.

When you do, an awful lot of the day turns out to be prediction. Writing code is predicting an implementation that meets a spec. Writing a user story is predicting what a customer needs based on what they tell you. Estimating is, well, predicting (and as I wrote in July, planning is harder than we admit). AI is getting very good at the first two and is at least confident about the third.

The economists' point is that when something gets cheap, the things that go with it become more valuable. For prediction, that's judgment:

• Deciding what's worth building

• Whether what came back is any good

• Whether to do anything at all

Google's DORA team reached a similar conclusion from a different direction. Their 2025 State of AI-assisted Software Development report describes AI as "an amplifier" that "magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones."

That's given me a useful question to ask of any practice. Is it mostly helping us produce more, or helping us judge better? I suspect a lot of what we do lands in the first bucket.

The values hold. The scaffolding is up for grabs.

Have I changed my mind about the importance of Scrum in this AI-enabled world? A bit. Back in July I wrote that organizations didn't need a new AI operating model, they needed to actually use Scrum. I still think that's true for most of them. Plenty of the organizations that tell me Scrum doesn't work have never really tried it as written.

But I'd be kidding myself if I said nothing had changed. A fair amount of Scrum's structure is there to manage batches of human work: the Sprint as a container, the Sprint Backlog, a lot of what happens in Sprint Planning. All of that made sense when building was slow and expensive. The ideas underneath it (empiricism, real goals, a Definition of Done people take seriously, and a team that owns the result) matter more with AI around, not less.

The Sprint is a good example. It has always done two jobs at once. One is learning: how often a team tries something, looks at what happened, and changes direction. That should go as fast as the experiments allow. The other is governance: how often the team sits down with stakeholders to get feedback and makes commitments. That one should be predictable, and speed isn't really the point. For years both jobs fit comfortably into the same two to four weeks. With AI, they're starting to come apart. In April I suggested sizing the Sprint to the humans, not the AI. Looking back, I think that was only half the thought.

Teams are shifting too. In The Cybernetic Teammate, a field experiment with 776 professionals at Procter & Gamble, individuals working with AI matched the performance of teams working without it, and AI also broke down the usual functional silos. I don't read that as "teams are finished." I read it as a change in why we put people together, with less emphasis on dividing up the building and more on combining judgment.

How far all this goes, I don't know yet, and neither does Alan. In the paper, we lay out two different readings rather than pretend the evidence has settled it.

So what's an operating model for now?

Most operating models I've seen were built around one assumption: Building is expensive. Annual funding cycles, approval gates, handoffs between departments, and big up-front plans are all, in one way or another, ways of rationing build capacity. If building stops being scarce, much of that machinery ends up guarding a door nobody needs to guard anymore.

My current thinking is that an operating model now has three jobs.

• It has to give people, and increasingly their agents, a clear sense of direction, which means outcomes you can actually measure.

• It has to ensure a named person owns each outcome, no matter who or what built it.

• It has to keep the evidence coming, in loops short enough that you find out whether the work changed anything before you've built the next five things on top of it.

What comes after Scrum?

I'm working on what that looks like in practice, including what I'd keep from Scrum and what I'd let go, plus a shorter list of principles that leaders can actually remember in a meeting. I'll share both soon as drafts, because I want other people who've done the work to poke holes in them.

The one thing I'm fairly sure will survive is that agents can do the work, but only people can be accountable for it.

Where to start?

If you want the longer version now, Alan and I have published our white paper, From Production to Judgment: What AI Changes in Agile Product Delivery. It pulls together what the research says as of October 2026, looks at the six practices we think change most (cadence, the backlog, the Definition of Done, team design, accountabilities and measurement) with something to try for each, and sets out those two readings of where things might go. We wrote it for people who already work this way, whether that's senior developers, Product Owners, Scrum Masters or heads of development, and who want a clear view of what to keep and what to rethink.

As for what comes after Scrum, I'm not sure anything does. I think the most useful work is remembering what Scrum was for and clearing away whatever has started getting in the way.

Disclosure: I drafted this post with help from Claude (Anthropic). The ideas, the opinions, and any mistakes are mine.