All articles

Scrum Isn’t Broken. It Just Doesn’t Fit Anymore.

What happens to our processes when AI is no longer the new thing, but the normal thing?

Scrum was built for a world where the path from idea to software is long, uncertain, and expensive. Where you need two-week iterations because the cost of going in the wrong direction for longer is too high. Where daily standups exist because coordination between humans is the bottleneck.

That world is disappearing. Not overnight. But fast enough that the cracks are showing.

Scrum isn't broken. It was built for problems we're solving differently now.

A Day in 2030: The Developer

It's 8:30 AM. You sit down, coffee in hand. Your AI agents have been working overnight. Three pull requests are waiting: a migration script, a performance optimization for a query that hit the alerting threshold, and a new API endpoint that a product decision yesterday made necessary.

You review. Not the code line by line – the AI handles syntactic correctness. You review the decisions: Is the migration strategy right? Does the optimization address the root cause or just the symptom? Does the API fit the existing contract architecture?

By 10 AM, all three are merged. You spent ninety minutes making decisions that would have taken a team of four an entire sprint.

Now: Do you need a daily standup to report this? A sprint board to visualize it? A sprint review to demonstrate it?

A Day in 2030: The Product Owner

The PO sees real-time data: which features are used, where users drop off, what the support tickets say. She doesn't need to wait for a sprint review to know what's working.

She describes a problem. The AI generates three solution approaches with effort estimates and trade-off analyses. She chooses one and triggers implementation. Two hours later, she sees a staging deployment and tests it herself.

Sprint planning? The "sprint" is a morning.

Why Each Ceremony Loses Its Purpose

Sprint Planning: Planning made sense when implementation was the bottleneck. When you needed to carefully allocate limited development capacity across competing priorities. When the cost of context-switching was high. With AI amplifying individual capacity by 5–10x, the planning granularity of a two-week sprint is too coarse. You don't plan what you can do in twenty minutes.

Daily Standup: The daily exists because people lose track of what others are doing. In a team of two or three (the likely team size when AI handles implementation), you know. You sit next to each other. Or you share a channel that updates in real time. The ceremony adds friction without adding information.

Sprint Review: Showing stakeholders what you built every two weeks made sense when building took two weeks. When something goes from idea to production in hours, the review cadence needs to match. Continuous demos, async updates, real-time dashboards – all more efficient than a biweekly meeting.

Retrospective: The retro assumes a recurring rhythm where patterns emerge. "We keep underestimating backend tasks" – relevant in a world where estimation matters. In a world where implementation is near-instant, the feedback loop is the code itself. What works stays. What doesn't gets replaced immediately.

Refinement: Breaking down stories into implementable chunks was necessary when handoffs between roles were expensive. When the same person who understands the requirement also generates the implementation, the translation layer disappears.

The Impact on Project Business

This isn't just a process question. It's a business model question.

Time-and-materials contracts are priced on effort. Fewer people times fewer days equals less revenue. Fixed-price contracts assumed a certain relationship between scope and time. When that relationship changes by an order of magnitude, pricing models break.

Small teams with AI will outperform large teams without it. Not marginally. Dramatically. And clients will notice. They're already noticing.

What Replaces Scrum

I don't think there'll be "the next Scrum" – a single framework that everyone adopts. Instead, I see principles emerging:

Continuous flow over fixed iterations. Work moves through the system as fast as decisions allow. No artificial two-week containers.

Outcomes over output. Measure what changed for users, not what was deployed. The amount of code shipped is meaningless when AI generates most of it.

Experimentation as default. When building a prototype costs hours instead of weeks, you don't discuss hypothetical features in a planning meeting. You build three and test them.

Small, autonomous teams. Two or three people who own a product surface end-to-end. No handoffs, no coordination overhead, no dependency management.

The Elephant in the Room

In many German enterprises, Scrum isn't just a process framework. It's a governance tool. Sprint reviews are accountability checkpoints. Velocity is a metric for management reporting. The Scrum Master is an organizational buffer between the team and stakeholder pressure.

Removing Scrum in these contexts isn't a process change. It's a political change. And political changes in enterprises are harder than technical ones.

The Human Side

There are people whose entire careers are built on Scrum. Scrum Masters, Agile Coaches, SAFe consultants. This isn't their fault. The industry told them this was the way. Certifications, conferences, communities – an entire ecosystem built around frameworks that are losing their purpose.

I don't think these people become useless. The skills underneath – facilitation, conflict resolution, organizational awareness – are valuable regardless of framework. But the job title and the specific toolbox will need to evolve.

The honest answer is: we don't know exactly what comes next. But pretending that two-week sprints and daily standups will still make sense in 2030 isn't honesty. It's denial.


Scrum wasn't wrong. It was right for its time. A time where software development was slow, expensive, and unpredictable. That time is ending. Not because Scrum failed, but because the conditions it was designed for are changing.

The teams that adapt early will have an advantage. Not because they abandoned Scrum, but because they understood why they were using it in the first place – and found better answers for a different world.