Dual-Track Is Two Kinds of Work, Not Two Teams

Your team ships fast. That part works. What breaks is what happens before the ship: someone figures out what to build, writes it up, and tosses it over the fence to the people who build it. The builders inherit a plan they never questioned. The learners walk away the moment code starts. You end up with two groups pointed at two goals, and the product pays for it.

Dual-track agile fixes this, but the name fools people. Two tracks sounds like two teams. It is not. It is two kinds of work that one team does at the same time. Get that wrong and you rebuild the old fence with a new label. Get it right and your team learns as fast as it ships.

Two kinds of work, one team doing both

There are two jobs happening at once. Delivery work is about predictability and quality: build it, test it, make it good enough to ship. Discovery work is about fast learning: figure out if you are building the right thing before you spend real money on it. Jeff Patton draws them as two tracks because they are two kinds of thinking, not two rosters of people.

The trap is reading that picture as designers plan while developers wait. Patton says he hates the term for exactly this reason. "If the whole team is responsible for product success, not just getting things built, then the whole team understands and contributes to both kinds of work." A product manager, a designer, and a senior engineer might lead discovery. They do not own it alone.

When you split the team by track, you get the same handoff you were trying to kill. Keep it one team with two jobs.

Run discovery a step ahead, not a phase before

Discovery is not a stage you finish before agile starts. It runs alongside delivery, continuously. A common myth Patton calls out is that discovery precedes development. It does not. You practice discovery with the same lean habits you use for shipping.

The useful gap is small. At Pop Pays, discovery runs one to two sprints ahead of delivery. Far enough that delivery always has validated work waiting. Close enough that what you learned last week still matters this week. Desiree Sy's original model, written up by Product School, shows designers working a cycle ahead while developers build the round that was validated last cycle. The same feature passes back and forth many times before it is done.

If you feel pressure to rush discovery to feed the builders, that is a signal. It usually means you are choosing to build before you have learned enough to be confident.

Two velocities, and you only measure one

Most agile teams track one number: delivery velocity. How much did we ship this sprint. But there is a second speed that matters just as much, and few teams watch it. Learning velocity. How fast are you finding out whether what you shipped was worth shipping.

David Denham argues Lean and Agile lean too hard on delivery and skip the learning half. A team can hit every sprint goal and still build the wrong product for a year. Speed at building the wrong thing is just expensive.

A discovery loop is built for learning, not for working software. You state your bet: the problem, who has it, what you would build, how you would measure. You pick the scariest assumption and run a cheap test. Then you decide: build it, kill it, or keep learning. Doing discovery right means killing ideas. If nothing dies, you are not really testing anything.

The handoff is the disease, not the cure

The over-the-fence handoff is what dual-track exists to remove. Shamsi Brinn describes the designer's version of it: creating in isolation and tossing artifacts to dev. The designer finishes a spec, walks away, and never sees what the tradeoffs did to the idea. That is not collaboration. That is a relay race.

Product School tells a story that shows the cost. Marketing wanted a 25% annual discount. Customers liked it. Engineering asked hard questions about whether it would scale to future promos. Under pressure, the team shipped a one-off that worked. Next quarter, marketing wanted a BOGO promo, and the setup was too rigid. Engineers started over. A team focused on outcomes would have built a flexible promo system the first time.

Shared ownership of the outcome is the fix. When designers and engineers both own the result, not just their slice, the questions get asked before the code, not after.

Make the work visible on one board

All of this can stay a nice idea unless it shows up where the team looks. Discovery work is often invisible. It happens in someone's head, in a doc, in a hallway, and it never hits the board. That hidden work clogs your flow because nobody can see it, plan it, or question it.

Sean Morrison shows the practical fix: tag Discovery and Development tickets on the same Kanban board and timebox the discovery ones. A discovery ticket has a clock on it, a few hours to a few days, because its job is learning, not perfection. When both kinds of work sit on one board, the whole team sees what is being learned and what is being built. No separate systems, no separate teams.

The deep cut

The part that changes everything: discovery does not stop when you ship. Jeff Gothelf, quoted by Patton, treats production software as your last and best experiment. You built it, users are using it, so keep measuring what it actually does. The old model ends at launch and calls it done. Dual-track never ends. The feature you shipped last month is still data.

This is why splitting into two teams fails. If discovery is a phase that ends and delivery is a phase that begins, someone hands off and walks away. If it is all one continuous loop of learning and building, the same people stay on the outcome the whole way through. There is no done column. The cycles run until the outcome is real, and then they keep running to see if it held.

Three questions for your team

1. How fast is our learning velocity, not just our delivery velocity? If you can name last sprint's ship count but not what you learned from it, you are only measuring half the work. Pick one number for learning and put it next to your velocity number.

2. Is hidden discovery work clogging our flow? Look at your board. If the research, tests, and validation are not on it, put them on it with a timebox. What you cannot see, you cannot plan or question.

3. Are designers and developers really on one team, or are we still handing off? Trace one recent feature. Count how many times it crossed a fence untouched. If discovery ended before delivery started, you have two teams wearing one name.