I Run Three Sprints a Week. I'm Not Sure They're Sprints.

I've known the words for twenty years. Scrum, Agile, Waterfall, sprint, story, backlog, velocity. You can't spend that long in IT and not soak up the vocabulary. What I hadn't done, until recently, was actually run the thing. Manage the developers. Own the rhythm rather than watch it from a distance.

A few weeks in, I caught myself saying "sprint" about a piece of work that took an afternoon. The word came out and felt wrong. Like wearing a coat two sizes too big.

Take a bug from last week. A customer spotted that the way they submitted tickets was tripping a script warning. A genuine defect, raised by a real customer, exactly the kind of thing that used to eat a fortnight.

The old shape went like this:

• Get a copy of the customer's database.
• Stand their setup up on our side.
• Try to reproduce the fault.

Half the time we couldn't, so we'd file it as "environmental" and spend the next month going back and forth with the customer chasing a ghost, ending up somewhere neither of us was happy with. That was the bad path. The good path was that we could reproduce it: work through theories one at a time until one held, build a QA piece around the fix, and call it two to three weeks.

Last week's version went like this:

• Open the codebase in Cursor with the full context loaded.
• Hand it the problem.
• Verify the leading hypothesis. It holds first time.
• The test harness is already wired up, so the patch gets validated on the way through.
• The README more or less writes itself.

The support desk contact the customer to walk them through the patch, and on SaaS it's applied that same evening.

Two to three weeks, gone to two to three hours. Sometimes less. That's what I'd just called a sprint.

So I went looking for whether anyone else had noticed, and it turns out the whole industry is mid-argument about it. Good. Means I'm not slow, I'm just on time.

Here's what I think actually happened.

The two-week sprint was never really about two weeks. It was a container sized for a constraint. Writing code was slow and expensive, so we built the entire lifecycle around measuring twice and cutting once. We groom the backlog and argue about requirements because engineering cycles are precious and you can't afford to burn them on the wrong thing. The ceremony made sense because the work underneath it was heavy.

AI pulled that constraint out from under the whole structure. When the model writes the first pass in minutes, two weeks stops being a unit of work and quietly becomes a unit of habit. The container didn't shrink when the work did. That's the gap I keep falling into.

The part that reframed it for me is where the hard work went. Agoda put out a piece arguing that AI raised how much each developer produces but barely moved project-level velocity, because writing code was never the real bottleneck. The bottleneck moved upstream, to working out what to build and then proving it actually works. It's the same shift I described when I argued that the moat was never the code. Andrew Ng says it flatter than that: the bottleneck now is deciding what to build.

I work spec-first, and have done since before I was managing anyone. Write the intent down properly, get the thing unambiguous, then let the build follow. For years that felt like a personal quirk. Now it turns out it's aimed squarely at the only bottleneck left. Which is a strange thing to discover by accident. I've come to think the parts of the job that actually decide the outcome were never the technical ones.

It also flips the "I'm new to this" worry on its head. Being new to managing developers means I'm not defending a two-week ritual I spent a decade perfecting. There's nothing to unlearn. The people who find this hardest aren't the newcomers, they're the ones with the most invested in the old shape. I've argued before that the thing breaking most AI strategies is ego, not capability.

Before this turns into another "Agile is dead" victory lap, the data says sit down.

The numbers back the worry:

• DORA measured a 7% drop in delivery stability for every 25% rise in AI adoption in 2024; its 2025 follow-up found the throughput hit had reversed, but the stability problem hadn't.
• GitClear's analysis of 211 million lines of code found duplicated blocks (five or more repeated lines) jumped eightfold during 2024 alone.

Speed without a boundary doesn't hand you a better product. It hands you a bigger mess, faster.

And the framework crowd have a fair point I didn't want to concede. Faster feedback makes the inspection point matter more, not less. Pull out the goal and the fixed checkpoint and you don't get freedom, you get a team iterating in circles, shipping constantly, with no shared idea of whether any of it landed. Constant motion is not the same as progress. I've watched that happen for half a day and it's unsettling, because everyone looks busy.

So here's where I've landed.

The sprint used to do two jobs on one clock. It paced the delivery, and it paced the conversation. Those were welded together because they had to be: a demoable increment took roughly a fortnight, so the conversation happened roughly every fortnight. AI split the two apart. Delivery dropped to hours. The conversation, are we building the right thing, is anyone stuck, did that feature earn its place, didn't move much at all. It's still a human-speed problem.

My three-a-week isn't three sprints:

• Monday I set direction.
• Wednesday I clear whatever's jammed.
• Friday we look at what shipped and ask whether it deserved to.

Those aren't delivery cycles. They're decision checkpoints wrapped around a build that basically never stops. The word "sprint" assumes those two clocks are still one clock. They're not. That's the entire reason it feels wrong coming out of my mouth.

None of this arrived by memo. We earned it the slow way, and I'll be straight about the cost.

The first decision was the uncomfortable one. We took the foot off net-new feature work for a stretch and pointed the team at learning instead. You can't ask people to change how they build and keep the delivery clock at full tilt at the same time. Something gives, and I'd rather it be a slice of roadmap than the quality of how they come out the other side.

Then we picked the edible parts first. You don't hand someone the gnarliest corner of a codebase that's been growing for two decades on day one of a new way of working. Three people, three different doors in:

• The developer started at the modern end, a two-year-old React self-service portal, with a warm-up that was almost boring on purpose: update the stack, clear the dependencies, get a feel for building with Claude Code where a mistake costs nothing. Then a run of eight enhancements straight off the backlog, to turn the new way from a novelty into a habit.
• The QA has spent months in Cursor building a new intent-driven chatbot for Solvyr®, and now has a test harness wired to Jira over an MCP, so the stories update themselves as the work moves. As he put it in Friday's check-in, writing all those test scenarios by hand from scratch used to take days; Cursor now drafts them in minutes, sometimes seconds.
• The product analyst runs our documentation through Document Studio, a tool I built with Cursor that turns the old document monoliths into something people can actually use: FAQs, a cheat sheet, How-Tos, a Quick Start. He uses it to produce the release notes for the new product and publish them straight into our Knowledge Centre.

All three further along than they were.

The genuinely hard legacy is still ahead of us, and here's the quiet bet underneath the plan: the parts that are hardest for a human to hold in their head are often exactly where this way of working pays off most. But you earn the right to point it at the hard stuff by building the reflexes on the easy stuff first. Skip that and you've handed them a faster engine and no idea how to steer.

I'll be honest about the rest, because the tidy version would be a lie. It's been a struggle, and it still is. Changing how experienced people work is far harder than changing a number on a whiteboard. I stopped the daily stand-up, which felt like pulling a handrail off the stairs, right up until it didn't, and some days it still does. They're moving in the right direction, all three of them, but "moving in the right direction" is carrying a lot of honest weight in that sentence. If you're reading this thinking it sounded easy, it wasn't, and it isn't.

If it's any comfort to anyone else feeling the same friction in their own stand-up, the people who name these things for a living can't agree either:

• Capgemini's Steve Jones reckons agentic development has killed the Agile Manifesto outright.
• Forrester says 95% of teams still find Agile relevant.
• Kent Beck is calling his version "augmented coding."
• AWS is floating "Intent Design" in place of sprint planning.

Nobody's won. I'm hearing the same shape from other teams I trade notes with, a few of them meeting twice a day, all of us re-setting the human clock by hand and none of us landing on the same number. So if you're standing there wondering whether the word still fits the work, you're paying attention, not falling behind.

Here's my actual position, for what it's worth.

Stop protecting the sprint. Start protecting the decision. The ceremony's job has changed underneath us, from controlling the pace of delivery to defending the quality of judgement, and most teams are still running the old meeting for the old reason. The question isn't "what did you build." The model built plenty. The question worth three checkpoints a week is "should we have."

I still don't know what to call them. I've stopped worrying about that. The name will catch up eventually. The work won't wait for it.