Your Scrum Team Didn't Get Obsolete. Some Of Its Mechanics Did.

I’m not going to tell you to be careful and not throw Scrum away. If I’m an engineering leader right now, I actually think I should question everything. With an agentic development lifecycle, things that used to take days can take minutes or hours, and a lot of the mechanics genuinely start to feel obsolete. Some of those individual mechanisms or roles might actually become obsolete, and I’m very open to that.

But I want to separate the mechanism from the capability. Don’t assume that because the mechanism became obsolete, the problem became obsolete. Take the opportunity to throw everything up in the air, and when things come back down, make sure you haven’t accidentally thrown away capabilities you still need just because you didn’t like the old mechanism that provided them. The risk I’m seeing is fragmented, misaligned progress: activity that’s not really pushing in the same direction, moving faster than ever.

There are real things that are changing. This isn’t just people looking for an excuse to get rid of Scrum. The teams and leaders I work with are implementing agentic lifecycles and they’re not clear how to map that to their ways of working, or what it means for their Scrum. A task that used to take a person hours now takes minutes, and often it’s just something an AI agent does. A story that used to take days now takes minutes too. It might start in a conversation between a human and an agent, but the agent does most of the implementation work.

A lot of the ceremonies and activities people associate with Scrum, sprint planning and the daily Scrum in particular, describe something that now happens much faster and requires fewer people and less collaboration between them. So naturally people start asking: why do I need Sprint Planning? Why do I need to wait for a Sprint? Why do I need a Daily Scrum? Why do I need all of these artifacts?

And they’re removing them. Mostly they’re cutting ceremonies and cutting artifacts. I’ve heard people saying we don’t need Jira anymore, we do everything in PRs in GitHub. Engineers are essentially saying we don’t need all of this process around us, we can just work.

You also need to understand the bigger context here. The teams I see this happening the most in are the teams that were suffering from Agile Theater and Agile police. Those were teams going through the motions of these ways of working without really getting the value from them. They were doing sprint planning because you have to do sprint planning. They were using stories because that’s what you do. They weren’t really using them to create shared understanding across a group of people, and they weren’t using them to create alignment. So from their perspective, the moment they can get away with throwing them away, the better.

It’s also an interesting situation where changing to an agentic lifecycle, because it’s driven more by engineers and technical types, is bypassing a lot of the Scrum police or Agile coaches or Scrum Masters, and the engineers and engineering leaders are enjoying that. It got to a point in the industry where they didn’t value the advice they were getting from the Agile world. So now AI comes along and suddenly there’s a very legitimate reason to question everything.

I don’t think the answer is “be careful, don’t throw Scrum away.” The point is to understand why those things existed in the first place. What problem was Sprint Planning solving? What problem was the Daily Scrum solving? What problem was the Sprint Review solving? Then ask whether that problem still exists. Maybe AI eliminates it. Maybe AI changes it. Maybe it moves somewhere else. But don’t assume that because the mechanism became obsolete, the problem became obsolete.

The Daily Scrum is the obvious example. If agents are doing work in minutes, having a daily synchronization around tasks may make absolutely no sense, and that task-level coordination might largely disappear. But that doesn’t mean coordination disappears. You can have several people or agents moving incredibly fast in different directions, all of them locally successful, and collectively create something incoherent. So the coordination problem might actually become more important. It just moves up a level: maybe we’re not coordinating around tasks anymore, maybe we’re coordinating around features, specs, outcomes, product direction.

Picture what these environments actually look like now. You have a set of people, and it’s not necessarily even a team. There’s this notion of the smaller pods. You don’t need a lot of people to work on stuff, so someone might work alone with their agents, or with one or two others, and each of those groups is working towards delivering a feature.

The expensive problem that could still happen is that they’re not aligned. Even assuming those features are real features that deliver customer outcome, there’s still a chance that by working from different perspectives or towards different features, they’re creating a fragmented experience. And the reality is that in many of these environments they’re not really working on separate features at all. They’re calling their things features, but those are still slices of something that should support a bigger outcome.

What you see in these environments is that the integration is simply not happening. The synthesis across, the alignment, the sensing and responding to what we can learn from the decisions we’re making about these features and what we’re seeing while building them: there simply isn’t a place for any of it. It creates a vacuum. Organizations that still need multiple people working on the same product, towards shared outcomes, need that alignment. They need that ability to sense and respond.

If everybody is moving slowly, misalignment is expensive. If everybody is moving ten times faster, misalignment becomes expensive ten times faster. That’s what I think we’re missing in some of these “Scrum is dead” conversations. We’re looking at how quickly an individual thing can now be built and concluding that the coordination structures aren’t needed. But organizations don’t have one developer working on one isolated thing. You have multiple things happening. You have dependencies. You have different interpretations of the intent. You have product decisions. You still need synthesis.

If I had 30 seconds with an engineering leader who’s ready to scrap all the rituals, that’s the one risk I’d name: fragmented, misaligned progress and activity that’s not really pushing in the same direction.

I’ve always been more flow-oriented anyway, so I’m sympathetic to the idea that a fixed two-week cadence can become artificial. If something can move through the lifecycle in an hour, saying “we’ll review that in two weeks” is obviously ridiculous. But there’s a danger in going from “this cadence doesn’t work anymore” to “we don’t need cadence.”

The counterargument is easy to make, and it’s even something SAFe acquiesces to in AI-native SAFe: you could always get together. Nothing is stopping you from getting together and aligning, or sensing, or reviewing, or discussing. There’s no need for a cadence for these people, and that cadence is artificial anyway.

One of the things I noticed early on, working with teams that chose to go full Kanban without a cadence and without a rhythm, is that the fact that it becomes a chore to get people together actually makes it harder. And people don’t do it. So it becomes a fragmented set of one-off conversations, where it’s harder to build shared understanding and shared context and to see the bigger picture. There’s actually value in doing these things together.

That’s what I’ve seen over the years, and I’m afraid that what we’re seeing now, with teams gravitating towards at best managing flow and throwing away a lot of their cadences, is something similar to those early Kanban teams that used Kanban as an excuse not to pay for the cadence of Scrum. From their perspective it was a payment, an overhead. They didn’t really see the value of it. And again, that’s because of the way it was mandated in their environment.

So I wouldn’t start from what I would keep. That’s almost the wrong question. I’d ask what the minimum mechanisms are that we need to prevent the expensive problems. If you press me for the one I’d insist on, I’d lean towards some sort of review, some sort of opportunity to sense and respond, to look at what outcomes we’ve already achieved and what outcomes we’re focused on, without diving too much into the details. Not a status meeting, not everybody reporting what they did. More like: here is what has emerged, is this coherent, what have we learned, are we still heading in the right direction, what decisions do we need to make. Maybe that’s daily in some environments. Maybe weekly. Maybe event-driven. The exact mechanism isn’t the important part.

I think the provocative thing right now is to say Scrum is dead, Scrum Teams are obsolete, Product Owners are obsolete, whatever. And some of those individual mechanisms or roles might actually become obsolete. I’m very open to that. But I want to separate the mechanism from the capability.

Don’t ask, “do we still need Sprint Planning?” Ask, “do we still have an alignment problem?” Don’t ask, “do we still need a Daily Scrum?” Ask, “do we still have a coordination problem?” Don’t ask, “do we still need a Sprint Review?” Ask, “how are we getting system-level feedback, and making sure all this incredibly fast work adds up to something useful?” That’s the more interesting conversation.

I wouldn’t argue that Scrum survives. I would argue that the Scrum Team didn’t become obsolete just because Scrum mechanics might. We still need people who collectively own an outcome. We still need different perspectives. We still need product judgment. We still need integration. We still need somebody looking across the work rather than only optimizing their individual agentic lifecycle.

The shape of that team could change dramatically. And some roles could change dramatically. But the underlying need for a group of people to own and make sense of an outcome doesn’t disappear because implementation got faster.

Next: Most Of Your Scaling Apparatus Is Now Optional. Your First Principles Are Not.