Dual-Track Agile: Discovery and Delivery in Parallel

What is it, and where does it come from?

Marty Cagan, at SVPG, says it is sometimes referred to as Dual-Track Agile, and he lists other names such as Dual Track Scrum and Continuous Discovery/Continuous Delivery. In his 2012 article, discovery is about quickly generating validated product backlog items, and delivery is about generating releasable software (SVPG: Dual-Track Agile).

The origin of the term is a bit tangled. Cagan says Jeff Patton first gave him the name “Dual-Track Scrum,” which he prefers. He had earlier called the approach “Discovery Sprints,” but dropped that name because it implied time-boxed discovery and serialized phases. Later, Cagan stopped using “Dual-Track Agile” and moved to talking about Continuous Discovery and Continuous Delivery because, in his view, it made people focus too much on process and not enough on principles. Patton draws the two tracks but says he dislikes the term, because it suggests separate teams rather than separate kinds of work (Zurb Radar).

What does each lane do?

ProductPlan places interviews, personas, and user stories in discovery, and moves only validated items to delivery. In delivery it lists prototypes, iterative user testing, and applying user feedback (ProductPlan: Dual-track agile). The key idea is that the backlog does not fill up with untested hypotheses.

Why does it matter to a designer?

Because design lives in discovery. Prototype tests, interviews, and synthesis of findings are design work, and in a dual-track setup that work runs one or two iterations ahead of development. Cagan describes the product manager, designer, and lead engineer working “side-by-side,” in contrast to mini-waterfalls, where artifacts pass from one role to the next.

Patton makes the same point: the two tracks are two kinds of thinking, not two lists of people, and the whole team understands and contributes to both kinds of work. He adds that discovery does not end at launch. According to the article, Jeff Gothelf treats production software as your last and best experiment (Zurb Radar).

How does work flow?

In a healthy flow, discovery stays “a step ahead, not a phase before.” Zurb Radar describes teams that keep discovery one to two iterations ahead, and shows an idea moving back and forth between the lanes several times before it ships (Zurb Radar).

A practical way to start:

1. Keep a board with two intake columns: ideas to validate and validated ideas.
2. Each week, the team decides which idea to validate and with which test.
3. Only items with enough evidence for the proposed scope enter the delivery backlog.
4. Measure learning, not just speed: how many hypotheses were tested and how many were dropped.

When should you NOT use dual-track?

• If the team is so small that one person does discovery and delivery in the same week, splitting lanes on a board may add more bureaucracy than help.
• If the organization does not let the team change priorities when it learns something, discovery will produce findings nobody uses.
• If the product is a regulatory change with a fixed scope, the discovery lane is nearly empty. Discovery shrinks to understanding the requirement, not choosing between options.

Cagan stopped using the term for the same reason: the model is a principle, not a ritual. If your team follows the ritual and not the principle, the problem remains.

Example

Illustrative example: a personal finance app team must decide whether to add spending alerts. In discovery, the designer runs five interviews and a paper prototype. She finds that users do not want an alert for every purchase; they want a weekly summary. The alerts idea is dropped before anyone writes code. Meanwhile, in delivery, the team finishes the category improvement that was already validated. Two weeks later, the weekly summary moves into discovery with a concept test. The delivery backlog never runs empty, because discovery is ahead.

If you want to learn how to work with the product manager in this flow, see working with product managers. To structure discovery tests, a research plan helps, and to turn what you learned into decisions, research synthesis.

Common mistakes

• Splitting the team into a discovery group and a delivery group, which recreates the handoff.
• Treating discovery as a phase before a closed specification.
• Leaving discovery work off the board, so nobody sees or measures it.
• Measuring only delivery velocity and not learning.
• Rushing discovery to feed the builders, so the backlog fills with unvalidated ideas.

What you can do tomorrow

1. Review your board and mark which cards are hypotheses and which have evidence.
2. Propose one discovery test for the next iteration and define in advance which result would drop the idea.
3. Ask your product manager which backlog item still has no evidence behind it.

Sources

• SVPG (Marty Cagan): Dual-Track Agile
• Zurb Radar: Dual track is two kinds of work, not two teams
• ProductPlan: Dual-track agile (glossary)