Part III. The Sprint with AI

Discover and deliver at the same time

Dual-track (discovery and delivery): why specs are not a waterfall

Six weeks without talking to a member

GymApp had never delivered so fast. In six weeks, eleven improvements had shipped: the spot availability alert, the class filter, the workout history, dark mode. Héctor opened every Sprint Review with a slide full of finished work.

Celia asked the awkward question in the Retrospective: when was the last time anyone talked to a member? Nobody could remember. The improvements came from app store reviews, from requests by the gyms and from the team's own ideas. All of them reasonable. None of them tested before they were built.

Ramón, who was there as a guest, added something else. Since the team had started writing specs (in Spanish) for the agents, someone on the committee had asked him whether they had gone back to waterfall: first the document, then the code.

The objection makes sense

The fear is reasonable. If everything starts with a spec, it looks as if we are back to phases: first you analyse, then you build. And waterfall failed for a reason: by the time you finished building, you found out that some of what you had analysed was not true.

But what makes a waterfall a waterfall is not having a document before the code. It is the batch size and the direction of learning. A hundred-page document written once and handed over to another team is waterfall. A half-page spec for a single item, written the week before it is built and corrected with what was learned in the previous Sprint, is not.

Two tracks, one team

Dual-track (discovery and delivery) (in Spanish) puts this in order. Desirée Sy described it in 2007, based on her design work at Alias (now Autodesk), and Marty Cagan made it popular. There are two tracks of work in the same team and in the same Sprint:

The discovery (in Spanish) track decides what is worth building. It talks to users, tests prototypes, looks at data and turns ideas into hypotheses backed by evidence.
The delivery track builds what is already validated, with quality and ready for production.

They are not two teams. They are the same people, with different weight in each track: the Product Owner and design carry more weight in discovery; the Developers and the agents, in delivery. But the Developers take part in discovery, because they know what is expensive and what is easy, and the Product Owner takes part in delivery, because they decide what is ready to ship.

Dual-track diagram: two tracks across four Sprints. In discovery, ideas A, B and C are validated one Sprint before they are built, and idea D is discarded; each validated idea moves to delivery as a spec and is built in the next Sprint; what is learned while building goes back to discovery in the same Sprint. Same people, same Sprint, different weight in each track.

The spec as the handover point

The spec is the border between tracks. An item moves from discovery to delivery when it has its spec: small, for a single item, with the evidence that justifies building it and with examples that make it possible to check it.

And learning flows back in the opposite direction. What you discover while building (that a case was not foreseen, that something is more expensive than it looked) goes back to the discovery track and changes the next specs. That return path is what waterfall did not have.

With AI, one track eats the other

With AI, the delivery track runs so fast that it can eat the other one. If building something takes an afternoon, it seems absurd to spend a week checking whether it is needed. It is exactly the opposite: the cheaper it is to build, the more things get built without being checked, and the more expensive the whole becomes.

That is why discovery needs reserved capacity. Not "when there is time", because with AI there is never time: there is always something else to deliver.

What it looks like in the Sprint

On the board, two areas: what is being discovered and what is being built, with a work-in-progress limit (in Spanish) on each one.
Product Backlog refinement (in Spanish) is the border between discovery and delivery: that is where features with low business, technical and functional risk are turned into a spec.
The Sprint Review looks at both tracks: what has been delivered and what has been learned, including the ideas that were discarded.
The Sprint Goal can come from either track: delivering something or resolving an important question.

GymApp decided to reserve two days per Sprint from Celia and Héctor, and half a day from one developer, for the discovery track. The first question it had to answer was the one that had been hanging in the air for months: what do the members who cancel actually do?

In short

Specs are not a waterfall if they are small, frequent and learning flows back. Two tracks in the same team and the same Sprint: discovery decides what is worth it; delivery builds what has been validated. With AI, you have to protect the first one.

Try it this week

Reserve a fixed part of the next Sprint for discovery, even a small one, and write down what question it has to answer. In the Review, report what you have learned in the same detail as what you have delivered.

If someone in your company still sees specs as a waterfall, the article Is Spec-Driven Development waterfall? (in Spanish) answers in more detail, depending on the type of application.