Dual-track Agile

Teams used to finish discovery first and start building afterward. A month of customer conversations and screen sketches decided what to build, the result was handed to engineering, and construction began. The sequence looks tidy on paper. Two things went wrong in practice.

The first is that engineering waits. A month with no decided work means picking up leftovers or low-priority cleanup. The second problem runs the other way: once construction starts, discovery stops. Nobody checks what comes after the current three-month build, so on the day it ships, another month-long discovery phase starts from scratch.

Planning conversations landed in the same place every time. Engineering would ask what comes after next week's release, product would say the interviews need two more weeks, and nobody could leave engineering idle for two weeks. So a half-checked item got pulled forward and handed over, and two months later almost nobody used the feature. The team didn't skip the checking because they didn't know how. They skipped it because somebody was waiting.

Dual-track agile lays the same sequence out as two parallel lines. Instead of chaining discovery and delivery end to end, it runs them over the same weeks and lets discovery walk one step ahead. Agile development — short cycles that correct direction as they go — had only ever applied to the building half, and this extends it to the deciding half.

Overlap a discovery track and a delivery track inside the same cycle, and have the discovery track validate what the delivery track will build next cycle. One loop has five steps.

1. Split time, not the team. The discovery track is usually a product manager (PM) — the person who decides what gets built and why — a designer, and one engineer, each giving it a few hours a week. Leave the engineer out and ideas that can't be built will pass.
2. Pick one or two things to validate this cycle. These are the candidates the delivery track will pick up next cycle. Chase four at once and none of them finish.
3. Write down what has to be true for an idea to pass, as a hypothesis — a guess written so it can come out true or false. "Showing a sample document first raises first-document creation from 34 to 40 percent" has the number and the bar in it; "users will like sample documents" doesn't.
4. Check it the cheapest way available. Put a prototype — a throwaway build of the screens only — in front of five customers, or run a week of user research, watching and asking real users to gather evidence. Anything that fails here never reaches the delivery track. Nine out of ten candidates dying at this step is normal.
5. Move only what passes to the top of the product backlog, the ordered list of what the team might build next. When the next sprint opens, the delivery track picks it up, and the discovery track moves to the candidate after that.

On a four-week cycle, weeks one through four have the discovery track validating idea A while the delivery track builds idea B, which passed last cycle. In week five, delivery moves to A and discovery picks up C. Because the two tracks stay one notch apart, there is always a cycle's worth of validated work sitting in front of the delivery track.

It fits when what to build is genuinely uncertain and the same team keeps owning the same product. A team entering a new area, or one that doesn't yet know why users are leaving, can expect nine of ten candidates to be wrong — building without checking burns most of the engineering time available. It does nothing for work whose answer is already fixed. Contract development with a feature list in the agreement, or a screen that has to change because a law changed, has nothing left to validate.

The limits usually come down to headcount. When the same people sit on both tracks, whichever track has a deadline takes all the hours. If interviews slip every release week, what's running is one delivery track with discovery attached loosely to it. That's why many teams write the discovery hours into the week as a fixed block instead of leaving them to whatever time is left over.

The one-cycle lead also breaks easily. When validation runs late and next cycle's queue is empty, the delivery track picks up whatever it finds, which is where the two tracks stop being two tracks. Cutting the number of things under validation usually fixes it faster than adding people.

"This sprint the delivery track is building B, and the discovery track is running a prototype for C."

Confirming that two different things are moving inside the same cycle.

"C hasn't cleared discovery yet, so next sprint is A."

Nothing goes down to the delivery track before it has been validated.

"Discovery slipped a cycle and engineering has nothing queued for next week."

A warning that the gap between the tracks has collapsed and building is about to stall.

At Pagedeck, Mia opens every sprint with a two-row table. The left row is what gets built this cycle, the right row is what gets validated. Theo only has to read the left row. Noa draws the screens on the right and puts them in front of five customers. Midweek, Mia writes up what the right row produced and decides what moves over.

The right row is where it jams. On release weeks Theo can't make the discovery sessions, so ideas that turn out to be expensive to build clear the gate and come back a cycle later. Pagedeck moved the discovery session to the day after each release.

The most common misreading is that two tracks means two teams. The word track sounds like separate rails, so people hear it as an instruction to keep a product group and an engineering group apart. It actually describes one team dividing its time, with the same people appearing on both tracks. Split the team for real and you create a handoff document between discovery and delivery, which puts the old sequence right back — plus engineers building something without knowing why it was chosen.

Reading the discovery track as a preparation phase before development is the same mistake wearing different clothes. Explained in order, discovery sounds like it comes first and building second. But the two tracks share the same weeks from start to finish, and discovery doesn't stop for as long as the product is alive. Treat it as preparation and a team discovers for a few weeks, then builds for a year, and finds its roadmap back to guesswork by the second half.