What happens to the work when everything else moves?
Once the culture has moved, the organization is restructured and the skills are recalibrated, how does work actually flow day to day? Which processes survive, which die, and which new ones emerge?
My thesis: much of what we call agile practice today is built to solve a coordination problem that is disappearing. Meanwhile a new problem, decision quality under accelerated production, is growing at the same pace. Most organizations are still solving the old challenge and missing the new one.
AI makes bad ideas worse, not better
John Cutler has written sharply about this: AI accelerates existing patterns. If your processes were healthy, they get better. If they were broken, they get worse. His example is a team that bolts a “Governance Agent” and AI-generated PRDs on top of an already broken stage-gate system. Every broken mental model, now with AI.
I haven’t yet seen it go wrong in a Danish company, but I think it’s coming.
An early symptom is the job postings. Suddenly everyone is hiring an “AI Product Manager”. What is that role, exactly? A product manager who knows some AI? That’s not the answer. Writing AI in front of the job titles solves nothing. It just hides that the organization hasn’t thought about what actually needs to change.
Most organizations starting an “AI transformation” right now are automating their creaking processes instead of asking whether the processes still solve a real problem. The trap is set and the invitations have been sent.
That’s the open front for this entire layer.
The trap: skipping discovery
The first concrete danger sits in discovery. When prototyping is free, and you can build a working solution over a weekend, a powerful temptation arises: skip discovery. Steve Blank has warned against it for years under the banner “fall in love with the problem, not the solution”. That danger grows now, it doesn’t shrink.
Because when a CEO or middle manager can dictate a prototype and see it running the same evening, they fall in love with their solution. Not because of the research behind it, but because of the speed with which it came into being. It’s a whole new kind of organizational politics. The PM arguing for waiting and investigating is suddenly up against a prototype the CEO built over the weekend and is in love with.
There’s an extra wrinkle. When building is fast, the temptation also arises to just ask the customer what they want. “We’ll just ask, and then we build it.” It sounds sensible. It isn’t. Henry Ford said it over a hundred years ago: if he’d asked people what they wanted, they’d have said faster horses. The difference in 2026 is that you actually can build the faster horses, in a week, with an onboarding flow on top.
Rob Fitzpatrick describes in The Mom Test how good discovery questions are about the customer’s life and behavior, not about your idea. What did you do last time beats would you buy this. That discipline doesn’t get less important with AI. It becomes the most important one.
The most expensive feature is not the one that takes a long time to build. It’s the one that should never have been built.
The trap: back to waterfall
The second trap is more subtle. AI makes it tempting to write long spec documents and hand the rest to an agent. You can dictate the specification in an afternoon, give it to Claude or Cursor, and watch an entire feature get built in one long stream.
It looks like agile on the surface, “we ship fast”. It’s the opposite. It’s waterfall in new wrapping. The iterative loop, where we build a little, test on users, learn something, and build again, is facing its biggest test in twenty years. Because that loop requires discipline, and discipline is harder when the alternative (a big specification that just gets built) is this easy.
It takes harder processes than before, not softer ones. Short cycles. Frequent reviews. Explicit learning between each iteration. The opposite of what you drift into if you just let the AI run with the spec.
The disappearing middle
Karri Saarinen from Linear has written about a movement he calls “the disappearing middle of software work”. The point is that the middle of software development, translating intent into implementation, has been the core craft for years. It’s where most of the hours have gone.
That middle is getting thinner. AI agents produce working code from goals, context and tasks. The IDE becomes more of a code viewer than a code-writing tool. Which means the pressure moves to the two ends:
- In front: shaping intent. What should be built, which tradeoffs are acceptable, which constraints apply.
- Behind: review, test, release. Making sure that what came out actually did what it should.
Processes need to be designed around those two ends, not around the middle.
Scrum is a coordination tool, not a product tool
To understand how fast this is moving, look at what Scrum’s ceremonies actually do. Daily standup is information routing. Sprint planning is translation from business needs to tasks. Refinement is collective guessing about size. Retro is one of the few meetings that isn’t about coordination, and it’s also one of the meetings most teams skip.
Scrum solves a real problem: how do we keep track of who’s doing what, and how do we make sure information flows between people who otherwise wouldn’t talk.
That problem is disappearing. AI is exceptionally good at coordination. A system that knows what everyone is working on can replace standups. A system that understands capacity and dependencies can replace sprint planning. MCP servers, browser agents and growing context windows are the building blocks. The orchestration is missing. It’s coming.
When it arrives, Scrum has a problem: the framework is designed to solve a problem a system will soon solve better. The question is not how do we use AI in Scrum? It’s what do we do that isn’t coordination?
The new bottleneck: decisions
When coordination is automated and production accelerates, decision quality becomes what separates. The research is starting to catch up. A new study explicitly points out that the speed-quality trade-off in AI-driven decisions is fundamental, and that quality-first design is necessary to handle it (Majumdar, 2025).
I’m talking to Danish developers right now who confirm the pattern in their daily work. An example from a bank: the developer told me they were just sitting there waiting for a decision to be made, so they could move on. They knew what to build. It was the decision that limped.
That’s the new pattern. Execution is faster than decisions. Meetings become waiting rooms where people wait for a leader to hand down a direction. The sprint becomes shorter than the decision cycle. Everything that looks like productivity turns out to be queueing.
The solution isn’t more meetings. The solution is better meetings, and fundamentally different meetings. Meetings where we specifically make a decision, not where we coordinate.
Facilitation comes back, but not as before
A personal observation: the Scrum Master role has too often ended up as meeting scheduler. Fetching coffee and cake, timeboxing standups, tracking impediments in a spreadsheet nobody read. It’s not the role that failed. It’s the execution. The Scrum Masters I’ve worked closely with have rarely taken responsibility for outcome and transformation. So they filled the time with coordination rituals.
The superpower coming back is decision facilitation. Handling conflicts, gathering disagreement into a decision, pushing a group to choose instead of stalling. That ability has always been valuable, always undervalued. It becomes critical now.
It’s coaching, mediation and the art of decision-making in one person. It’s not a new role. It’s the Scrum Master role done properly. Anyone who wants to continue in the role after coordination is automated has to master it. It’s the difference between becoming redundant and becoming indispensable.
Which processes survive
I’m careful not to be too categorical here. The pattern goes beyond Scrum: any process that is primarily coordination is threatened. Any process that lives on reflection or decision becomes more important. My current assessment:
- Daily standups: die. AI is on its way to knowing better what everyone is doing, and people shouldn’t synchronize verbally when the system does it automatically. The research points the same way even without AI: a grounded theory study of 60 developers and 79 observed stand-ups across four countries finds that the most negative factors are status reporting to managers, too high frequency and too long duration (Stray et al., 2016), especially for senior developers.
- Sprint planning: thins out. Replaced by continuous prioritization with AI support and short decision meetings as needed.
- Refinement: disappears in its current form. Estimation matters less when build time collapses. Replaced by intent shaping: what is this task actually supposed to solve?
- Retros: become more important. One of the only meetings that lives on reflection rather than coordination. It should have been the biggest one all along.
- PRDs and requirement documents: living documents replace static ones. No requirements decided once and handed over.
- Roadmaps: quarterly plans are replaced by continuous prioritization. The annual roadmap exercise is a relic from a time when it took six months to build one item on it.
- Discovery cycles: get shorter but more frequent. Still core practice, not phase 0.
- Reviews and evaluation: grow markedly. The end of the process that has been underprioritized becomes where quality is decided.
- 1-on-1s and coaching conversations: become more important, same logic as retros. That’s where judgment and identity get moved. AI can’t automate that.
- Performance reviews: collapse in their current form. Output measurement doesn’t hold when everyone can produce more. Must be redesigned around outcomes and decision quality. The shift from output to outcome measurement is already documented in the public sector (Mas et al., 2019), and the research explicitly distinguishes between rigid top-down systems and dynamic systems based on outcome ownership (Liao et al., 2024).
- Stage-gate and governance reviews: change character. The concept of fixed gates is poorly suited to high uncertainty (Trott et al., 2022). When the cost of building collapses, the conflict sharpens: the organizational inertia keeping stage-gate alive is its integration into planning and budgeting, not that it’s the right tool. Approval has to move to after the build, on outcome, not on the planned effort.
Timing is part of the decision
Decision quality isn’t just about how well you decide. It’s about when.
A 2025 MIT Sloan study followed 579 teams through an internal innovation competition in a Fortune Global 500 company (Cromwell & Harvey, 2025). The researchers expected teams that defined the problem early and clearly to implement the most solutions. The opposite turned out to be true.
Teams that started with high problem clarity had a 50% implementation rate. Teams that started unclear and discovered the problem over time hit 80%+. The mechanism is twofold: broader idea exploration and deeper team commitment, because people are more committed to ideas they shaped themselves.
But, and this is the point, chaos is not the answer. Teams that hadn’t converged by the 50% mark dropped to a 25% implementation rate. Same study. The leader’s job is to shift gears: divergent leadership in the first half, convergent in the second.
That matches what I see in practice. The worst product decisions I’ve been part of fell into two ditches: either we decided too early (we hadn’t understood the problem) or too late (we were still debating direction when we should have been executing). AI makes both ditches deeper. When the cost of building falls, it becomes tempting to lock in too early, because we can build. And it becomes tempting to postpone, because we can generate yet another variant.
The new judgment isn’t just what you decide. It’s when. First half: keep the problem open longer than feels comfortable. Second half: close it down harder than feels comfortable.
The principle for this layer
The principle is short:
Time to learning. Time to delivery. In the right order.
It’s the opposite instinct of what most agile implementations are built on. They’re built around speed to delivery. That was the right optimization when building was expensive. It’s the wrong one now.
The research points the same way. A five-year multi-site study of large-scale agile in a multinational telecom company identifies six pitfalls where agile practice actively harms individual learning, ideation and exploitation (Annosi et al., 2020). Rita McGrath puts it even more sharply in the Journal of Management: in the digital economy, whoever learns fastest wins (McGrath, 2023).
When building is free, the only meaningful measurement is how fast you learn. With one caveat: fast learning can end up as many small experiments on whatever is easy to observe. Felin et al. (2020) warn against exactly that trap, that the learning cycle becomes so fast the hypotheses never get bold. The shift from speed to delivery to speed to learning is not a license to only learn small things. It’s a demand to learn about what actually decides the product.
Everything else, sprints, ceremonies, rituals, should be designed around that.