From Scrum to Shape Up in the AI Era

Agile and Scrum were genuinely brilliant for the era they grew up in, when developers were writing the code themselves and that work took real time. Sprints, backlog discipline, demos, retros… they made a massive difference to how we ship software, and for most teams it was nearly always for the better. They brought rhythm, focus, and a shared language for delivery that waterfall never quite managed.

I'm not writing this to throw that away or pretend it was all ceremony theatre. Those processes earned their place.

But since the start of the year (2026), for me it has felt like a genuine turning point in agentic workflows. The harnesses and the models are now good enough that agents can reliably get on with the work, as long as we humans take the time to properly outline what we actually want. Gone are the days of novelty autocomplete.

For me this has really changed the economics of a sprint almost overnight. The part of the job that used to dominate the calendar (writing the code) became one of the quickest bits. And a process that was optimised around developers writing code just doesn't scale in this AI world.

Now I know on paper this sounds like a pure win. Dev's getting through a tonne of code in the same 2 weeks. Sprint velocities almost doubling. What's not to like right! But in practice, it created a new kind of pressure.

If tickets can be burned through faster, the natural Scrum instinct is to pull more in. Keep the velocity chart happy. Feed the machine. Before long you're not shipping better software. You're on a factory floor, racing a process that was designed when humans still had to type most of the implementation themselves.

I've been feeling that tension at work. So as a team we got together to begin changing the process to match the era we're actually in.

In this post I want to share how we're moving away from classic Agile/Scrum towards a modified version of Shape Up, why that matters in the AI era, and what it has felt like personally on our first cycle. We're early. This is not a polished case study. It's an honest snapshot of a team adapting before burnout becomes the cost of "going faster".

Let's dive in.

When Code Stops Being the Bottleneck 🤖

The uncomfortable truth for a lot of teams right now is this: implementation is no longer the slowest part of the work.

Discovery still takes time. Talking to the people who actually live with the problem still takes time. Designing something coherent still takes time. Reviewing agent output carefully still takes time.

What no longer needs to eat half the sprint is "getting the code written".

One of the biggest issues I hit with Scrum in this new world is that the work stops being serial. It runs in parallel whether you planned for that or not.

I'd spend an hour with an agent on a story in the planning stage, get the intent clear, then kick it off. You don't want to sit there watching an agent grind through a task list, so you pick the next story in the sprint and do the same. Then the next one. By the end of the day you've probably finished three or four stories that would have taken days before, and you've likely got another two or three cooking overnight ready for review in the morning.

That feels incredibly productive. It also drops you straight into the drag more work in trap.

The board empties. The sprint commitment looks soft. Velocity looks "too low" against what you now know you can burn through. So you pull more stories in. Then more. Before long you're not deliberately choosing good work. You're feeding a queue of agents because the two-week container keeps demanding to be full.

If you keep a sprint model that was optimised around human typing speed, something breaks. Either:

• you cram more stories in to fill the newly available capacity, or
• you finish early and feel guilty that the board isn't "full enough", or
• you quietly lower the bar on design and review because the tooling makes it easy to look busy

None of those are great outcomes. The first two burn people out. The third burns the product. Parallel agents make all three easier to fall into without noticing.

So the question for us stopped being "how do we go faster?" and became "how do we spend the time we just freed up on the things that actually determine quality?"

That is what pushed us toward Shape Up. Not as a religion, but as a set of ideas that fit the new shape of the work much better than sprint theatre.

What We're Adopting from Shape Up 🛠️

We're not doing pure Basecamp Shape Up by the book. We already have a long-term roadmap, so some of the classic "betting table" mechanics don't map cleanly onto how we plan. What we are taking seriously is the spirit of it: fixed time, variable scope, proper shaping, and room to cool down.

Four-week cycles instead of two-week sprints

We've moved to four-week cycles:

• 3 weeks of build
• 1 week of cooldown

That alone changes the feel of the work. Two weeks was always a bit of a scramble, especially once AI shortened the implementation middle. Four weeks gives a problem room to breathe. You can design properly, build with intent, and still have space at the end to tidy, reflect, and set up the next cycle without immediately diving into the next pile of tickets.

The cooldown week is not a holiday. It's the pressure valve. It's where you clean up, document, improve tooling, close loops, and avoid the "start the next sprint already exhausted" pattern that two-week cadences can create when delivery is constantly compressed.

Appetite over estimates

This is one of the biggest mindset shifts, and for me one of the healthiest.

Instead of asking "how long will this take?" we're starting to ask:

• How much can we do in this time?
• How many cycles do we actually want to spend on this?

That's the appetite mindset. You decide how much of the team's focus a problem deserves, then shape the work to fit that appetite. Not by letting an open-ended estimate expand forever, or pretending a story point number makes uncertainty go away.

We still know the big rocks. The roadmap is there. We're not reinventing prioritisation from scratch every four weeks. What we're changing is the relationship between time and scope: time is the fixed container; the solution is what we fit inside it.

Small teams of two

We're also working a lot more collaboratively now, typically in pairs of two developers on a cycle.

That sounds simple, but it's not a small cultural change.

When agents can produce a lot of code quickly, solo hero mode becomes even more dangerous. You can generate volume without shared understanding. Pairing (or tight two-person teams) brings the design conversation, the review conversation, and the "is this actually good?" conversation forward into the work itself, not just the end of a PR.

For me, that collaboration has been one of the biggest quality-of-life wins. I'm not just throwing tickets over a wall to an agent and hoping for the best. I'm building with someone, thinking with someone, and catching the "this is quick but wrong" moments earlier.

Designing Before We Let the Agents Loose 🎨

Because coding is faster, we can finally afford to do something teams always say they value but often skip under sprint pressure: design properly first.

We're spending more time together in Figma before we start implementation. Or more accurately, before we let the agents loose on the codebase.

That order matters.

If you reverse it (code first, design later), AI just helps you dig a mess faster. If you invest in a clearer design and a shared understanding of the interaction, the agent work has something solid to aim at. You're not asking the model to invent product sense. You're asking it to execute against a direction the team has already argued about and agreed on.

This is where the AI-era process shift becomes real for me. The speed of code generation is not the product advantage. The product advantage is using that speed to buy better upstream decisions.

Collaborative Framing and Shaping 🧠

Framing and shaping are more collaborative for us now as well, and that has been good for both engineering and product.

Freeing product to get to the real problem

When engineering is flying through tickets, product ends up permanently on the back foot. They're constantly feeding the machine, writing the next slice, clarifying the next ambiguity, while the people closest to the actual problem (the SMEs) never get enough uninterrupted time with them.

By changing the cycle shape and slowing the "ticket factory" dynamic, we're giving the product team more space to do what they're best at: get to the root of the issue with the people who know the domain. Not just churn backlog items to keep a board looking healthy.

That matters more in the AI era, not less. Bad requirements implemented at superhuman speed are still bad requirements. They just arrive sooner and cost more to undo.

A dedicated developer on shaping each cycle

We're also putting a dedicated developer into shaping for the cycle.

We're hoping that this will be a quiet superpower.

Having engineering in the room while the work is being shaped means we leave with a much richer shared understanding. Not a ticket title and a vague acceptance criteria dump. A real picture of the constraints, the edge cases, the technical appetite, and what "done well" might look like.

It also stops shaping from becoming a purely product exercise that engineering only meets for the first time at sprint planning. By the time build starts, at least one developer has already been deep in the problem space with product and can help carry that context into the build pair.

What We're Not Doing (Yet) 🧐

Honesty matters here, because process posts get weird when they pretend a perfect framework landed fully formed.

We're not really running a classic Shape Up betting table. We already have a longer-term roadmap, so the big bets are often known. What we are adopting is the appetite thinking inside that roadmap: how much of the next cycle (or the next few cycles) a given problem deserves.

We're also only on our first cycle. That means a lot of this is still forming in practice. The ceremonies, the exact cooldown habits, the best way to hand context between shaper and builders... we'll learn those by doing them, not by writing a manifesto.

I think that's healthy. The point is not to replace one rigid process with another. The point is to stop forcing AI-accelerated delivery through a cadence designed for a different era.

If something in this model doesn't work, we'll change it. That is the whole point of adapting.

How It Feels Personally 💭

So what has all this meant for me personally?? This is the happiest I've been at work this year.

I'm no longer feeling pressured to drag loads of stories into a sprint because agents can chew through them so quickly. I'm no longer measuring a good fortnight by how full the "Done" column looks. I'm not on that factory-floor treadmill where speed is the only signal that counts.

I'm enjoying the collaboration with my teammate. I'm enjoying the space to design. I'm enjoying knowing that we're going to use this time to push quality up, not just throughput.

And here's the important nuance: we're not suddenly doing less meaningful work.

We're still aiming to deliver a volume of outcomes we're happy with, the kind of delivery we were already proud of in the earlier AI days. What we're refusing to do is keep accelerating past that point at the expense of quality, people, and product thinking.

Same ambition. Better conditions. Less panic.

It also means I've been able to start to learn Figma and really expand my (quote amateur) design skills. Something I would never have had the time to do before.

Closing

AI did not just change how we write code. It changed which parts of the software process are expensive.

If coding gets cheaper and faster, then design, shaping, collaboration, and quality judgment become the scarce resources. Keeping a two-week, story-point, fill-the-sprint model in that world is a great way to convert a productivity gain into burnout and brittle software.

We're choosing a different trade-off:

• longer cycles with a real cooldown
• appetite instead of endless estimation theatre
• pairs who design and build together
• product and engineering shaping with SMEs, not just feeding a backlog
• quality as the thing we reinvest speed into

We're early. We'll learn a lot over the next few cycles. But even one cycle in, the direction feels right. Not because a book said so, but because the work feels human again.

Call to Action

If your team has adopted AI coding tools but still runs the exact same sprint machine as three years ago, it might be worth asking a blunt question:

Are you using the extra speed to improve the work, or just to feed the process more tickets?

You don't have to throw out Agile tomorrow. You don't have to implement pure Shape Up. Start smaller if you need to: protect design time, try a longer cycle, put a developer into shaping, experiment with appetite on one initiative, give product room to think.

If this resonates, share it with your team and start that conversation. The teams that adapt their process to the AI era, not just their tooling, are going to be the ones who stay sustainable.

Let's build something great together 🚀