Dual-Track Agile

The backlog's full of features nobody validated. Discovery finished months ago. The team's building what was true then, not what's true now.

Dual-Track Agile is Jeff Patton's approach to running discovery and delivery as parallel workstreams rather than sequential phases. You keep one track validating problems and solutions whilst the other builds what's already been proven.

The unique strength is that uncertainty gets addressed continuously, not front-loaded and forgotten. Reach for it when your team ships features that technically work but miss what users actually need — the sign that discovery stopped when coding started.

It requires discipline to protect both tracks; delivery's urgency will cannibalise discovery unless you've ring-fenced capacity. It falls apart in organisations that still think in phases, or when there's no one dedicated to the discovery side.

Your next move: Whilst your team builds this sprint's features, who is doing the discovery work for next quarter — and if the answer is 'no one', what will you build then?

What it looked like for them

Plancast, 2010–2012. Plancast built a social platform for sharing future plans and ran a single track: delivery. Feature after feature shipped on schedule, each one polished, each one working as designed. The team was executing well. What they weren't doing was discovering whether anyone needed what they were executing on. Sharing future plans isn't a daily habit for most people, and no amount of well-built features could change that.

There was no discovery track running alongside delivery — no continuous testing of whether the underlying behaviour was habitual enough to sustain a product. By the time the growth numbers made the answer obvious, the team had spent two years delivering against an assumption they'd never validated.

Dual-track agile exists to prevent exactly this: discovery and delivery running in parallel, so the team learns whether the thing is worth building at the same pace it's building the thing.