A Sprint Is Not a Mini-Waterfall

Google released a whitepaper on the AI software development life cycle. A good one, in general. It aims to systematize the knowledge that's been emerging in fragments — blog posts, threads, conference hallways — and to draw the line between three modes people keep blurring together: vibe coding, AI-assisted development, and agentic engineering. That's a genuinely useful thing to do. These ideas are new enough that most teams can't yet name which one they're doing, let alone choose deliberately between them. Making them learnable is real work, and the paper does a lot of it well. (I've argued the spectrum between vibing and engineering matters more than any single tool, so I was glad to see someone put structure on it.)

But there's one chapter that doesn't hold up: the part where the new AI model gets compared to "agile."

The authors seem to believe that a sprint is just a small waterfall. Requirements for two or three days, then design for a day or two, then build, then test — the classic phase sequence, shrunk down to fit inside two weeks. It's a tidy picture. It's also a serious misreading of the last twenty to thirty years of how software delivery actually evolved.

What the picture gets wrong

Here's the idea it misses. The big move of the agile SDLC was not "do the waterfall faster." It was to remove the distinct phases from the iteration altogether.

Inside a well-run sprint there are no gates. Each feature naturally travels from a rough idea toward working software, passing through ideation, design, implementation, and testing along the way — but the cycle itself has no stages. Things happen in parallel. A developer and a product person shape a slice of behavior together while it's being built; a tester's question reshapes the design mid-stream; the "requirement" for the next feature gets sharper because the last one just shipped and someone looked at it. Nobody hands a finished requirements document across a wall to a design team who hands it across another wall to builders.

That last part is the whole point. Phases create handoffs, and handoffs turn colleagues into stations on an assembly line. Removing the phases is what lets a team co-create instead of passing gated tasks between workers. "A sprint is not a mini-waterfall" is a sentence we repeated constantly when teaching Scrum, precisely because this was the mistake everyone made first. One could have googled that.

I'm not raising this to score a point on a whitepaper. I'm raising it because the same misunderstanding is about to get baked into the AI-era lifecycle, and that would be a waste.

Three questions worth sitting with

The reason this matters isn't nostalgia for agile. It's that we're rebuilding the SDLC right now, in real time, around models and agents — and we get to choose what we carry forward. So:

🤔 What if we studied the best agile adoptions instead of building on the common misunderstanding of them? Most people's mental model of "agile" is the industrialized, ceremony-heavy version they suffered through — not the fluid, co-creating teams the ideas were meant to produce. Those good adoptions exist. DORA research consistently shows that value stream thinking — removing handoffs and wait time across the whole system — is what separates high performers from the rest. That's worth reading before we build the next lifecycle on top of a misread.

🤔 What if the "old" model isn't out of date at all? Iterative, incremental, phase-free development wasn't a fad that AI replaces. It was a hard-won answer to a real problem: how do you build something when you can't know the full spec up front? That problem hasn't gone away. If anything, agents make it sharper.

🤔 What if there's more to re-apply from the last decade than it looks? The failure modes we learned to name — the handoff, the gate, the local optimization that speeds one station while the whole system stalls — don't disappear when you add an LLM. They come back wearing new clothes. I've written about that in You Say You've Got an AI SDLC: a fast engine bolted onto a phased, hand-off-heavy org just produces the same traffic jam, more expensively.

If we take those questions seriously, we can skip a whole category of pain — the "agile theater and industrialization" era, where the mechanics of a method got copied while its point got lost — and put this genuinely wonderful new technology, LLMs and agentic engineering, to its full use. Google's paper is a good start. It'll be a better one if the next version reads a sprint for what it actually is.