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

I’m seeing organizations talking about spec-driven development. We don’t need Scrum. Maybe we need Kanban.

Groups that are feeling oppressed by the Scrum police are using AI and SDD as an excuse to throw Scrum out.

There are organizations that are getting rid of Jira. I don’t think that makes sense. In some of them, the technology organization is sick of Jira, is sick of Agile, and they’re just using AI as an excuse to just do whatever they want.

And maybe people want to get rid of product owners and scrum masters. Maybe there’s politics to flattening the organization this way.

And it’s easier to cut.

But some of it is real. It’s pretty clear that when you talk about who’s actually going to work together on something, it’s going to be those tiny pods. Things that used to take days can take minutes or hours. So a lot of the mechanics start to feel obsolete.

If I’m an engineering leader right now, I actually think I should question everything. 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.

I met a CEO of a cybersecurity AI-native firm, a friend from the Israeli community. One of the things they realized between their previous company and this company is that R&D used to be a defensive activity.

It used to be reactive. The bottleneck used to be in engineering, in R&D, in product. So we need to protect the bottleneck. All of our processes, all of Scrum, was about protecting that.

What they’re seeing now is that their whole organization is forward-deployed engineers. They’re going on the offense. That’s his language. He’s coming from cyber, state-level cyber, so he has that language of defensive and offensive.

For him, what that enables his company to do is things like unreasonable hospitality. You go into a Michelin restaurant and you’re surprised by how hospitable they are. They do things that are wowing you. They’re fulfilling dreams.

So the concept I’m starting to think about is: what would unreasonable agility look like?

What can we do now that the bottleneck has moved? That stops protecting. That stops acting from the point of, you only come to us once a sprint, you have to come with ready stories and all of that junk.

What can we actually do now that we’ve freed that constraint?

That’s the question underneath all of this. Not which ceremony survives. What was the ceremony protecting, and is it still the thing that needs protecting.

The fair objection is that nobody can yet say where the constraint went. If dev isn’t the constraint, what is? Businesses are confused about it, and most of the confident answers are guesses. The one shift people do report consistently is that the speed of oversight and human decision-making got compressed: the product managers and the VPs are getting crushed under a thousand tiny decisions.

Which is its own answer, if you’re listening to it. The constraint moved toward the people who have to decide.

There’s an open question around: are those tiny pods the teams? Or do you still have the notion of teams that those pods live in, and still do a lot of the same structures, just at one higher altitude?

I don’t know what the real desired state is. Is it really that we have tiny pods that have no connection to the bigger team? Or is it tiny pods are temporary for a while, but there is a bigger team that they belong to?

There are human aspects that this whole AI-first thing is kind of ignoring. From a stable structure perspective, I’m not sure you need to change the team structure. The pods can be how the work gets divided this week without being the org chart.

So: the team just discusses which features are we doing this sprint, and what are the tiny pods that are going to split off, break out, work on each one of these features.

Spec-driven development is a very popular approach to agentic development. It’s a core part of the lifecycle. And it raises the question in many organizations: do we manage stories the same way we used to?

Typically the answer is the stories are managed in the pod, in the tiny pod, maybe even just by the AI. The interface with the wider organization is not stories. It’s features.

There’s almost an interesting opportunity here. Jira now will have epics being real epics. And the stories, the issues, will be features. And finally, epics will be epics.

A lot of it is going back to flow. That’s definitely the case. In the agentic world, flow and Kanban are becoming more important.

But the more I think about it, I think there’s still value in a lot of the elements people are throwing away. Done at a different altitude. Instead of planning in detailed stories, outcome planning, talking about OKRs. Instead of managing stories in the sprint, managing features.

And detailed story planning was never the intent, just so we’re honest. The intent was to talk high level about outcomes and then do continuous exploration, continuous delivery throughout. It’s about time that this happened. AI forced their hand to do something they should have done a while ago.

The daily Scrum I don’t think is necessarily an event. No, I think it’s still daily something. I don’t know that it’s an event.

But looking ahead, I think Sprint Review still makes tons of sense. Even more.

That asymmetry is worth sitting with, because it’s the opposite of where most of the cutting is pointed. The event that coordinated people around tasks is the one that has the least left to do. The event that checks whether all of this fast work added up to anything is the one that got more important.

There’s this exercise that talks about the essentials (the small set of things a way of working is actually built on).

The real interesting piece is that at the end of each one of these essentials, there’s a list of symptoms that you might find.

I think it’s an interesting opportunity to ask: do we see any of these problems? Or do we believe that we’ll see any of these problems if we stop doing this thing? And if we believe we might see these, then we might need to invest in those principles.

Do we see these problems? If so, we need to make sure we have cadence and synchronization.

Which I think specifically is an interesting conversation to have. Because if you’re going to full flow and you’re ready to get rid of sprints and PIs, will we expect to see any of these symptoms? Do we expect to see any of these problems? And if so, what are we going to do about them?

And then it brings you back to: we might need some sort of cadence. Maybe it’s not the one that we have right now. But we might need some cadence.

The way this is useful is that it gives people the right perspective from a change management point of view. We’re doing this for a reason. We’re doing this to avoid these symptoms. We’re not doing this just because.

One thing you can do is cycle on the product operating model. What is right for disruption? What is something we need to rethink? What are some things that will continue to work as they are? And you can use that to drive the conversation around what needs to change.

And you could do the same about the role of the team. What does the team do that works well right now? What is the team doing that’s right for disruption, or destructive recreation? What are things we wanted to do, and now maybe start doing with AI supporting it?

And when someone brings you an agent to roll out: what’s the intent with these agents? Is the intent that they reduce the need for some roles, for some of the events?

Something interesting happened when we taught experienced Scrum practitioners about Kanban back in 2018. There was an interesting realization in the room about what Scrum was and wasn’t. If you ask me, that’s probably the most valuable outcome of what took place at the time.

AI is giving us another opportunity like that. To reflect on the assets. To define what this basically is.

And when you do that, what you land on isn’t a set of ceremonies. It’s a governance framework. It’s a risk reduction mechanism.

Which is also where it stays useful. Where it’s hard to observe the results of what we’re doing, where we’re close to the customer and still have to figure out what process needs to change, you need governance. Coding was never the part that needed it.

Nobody’s looking for a process to copy paste, and Scrum is not going to be that process to copy paste anymore.

I think we should almost take the word teams out, because you may have one person and a bunch of agents. So maybe moving away from all of our team vocabulary.

Now we have teams building software, and the next step is one person doing the work of a team. So the whole premise that we had 20, 30 years ago, even when we started Scrum, that’s just gone.

When you’re using AI, all the things that are wrong in your team are made even wronger.

When people asked when does Scrum not make sense, Steve used to say: when you don’t have a team.

I think it’s okay to say that when you’re managing your own work with your agents, maybe you can find using Scrum, but that’s not the intent. A lot of the principles would work.

But the real value of this thing is when you have a group of people, a team of people, that need to collaborate in some way towards an outcome.

It’s a team sport. It’s an optimized team sport.

You don’t have rules of volleyball when you are playing volleyball alone. That’s meaningless.

So don’t ask whether you still need Sprint Planning. Ask whether you still have an alignment problem.

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