I believe the vast majority of Agile approaches boil down to feedback, specifically where and how you are building your feedback loops. I like to map the steps of Agile development to the steps of the scientific method. I specifically view the product vision as a hypothesis: it is an educated guess based on what you already know—but you don’t know everything.

But what happens as you gain more knowledge?

Much like in the scientific method, the results of an experiment allow you to refute, refine, or reinforce your hypothesis. At a high level, this is equivalent to evaluating the product vision based on user feedback gathered from product testing.

You might be familiar with the Double Diamond diagram that captures this process:

Diagram produced by Digi-ark - Own work, CC0

The team conducts research, bases build decisions on that research, builds the product, and collects feedback that informs another cycle of research, build, and feedback.

It’s a sequential process, running in a series of steps from requirements gathering to product release, and it works well for a lot of applications. But using this approach isn’t always the most efficient, especially when it comes to software development. That’s where dual-track Agile comes in.

Dual-track Agile reduces waste

Dual-track Agile is not a new concept, and there are plenty of resources available that define and discuss dual-track Agile. But when I’m asked to explain dual-track Agile, I like to start with simple:

Dual-track Agile takes key steps in a serial process and runs them in parallel instead.

To me, that’s what it all boils down to. Going back to the feedback that is fundamental to Agile, by overlapping key steps, dual-track Agile opens up opportunities for more frequent, focused feedback between the research and decision-making steps.

So, that Double Diamond diagram? 

Rather than appearing as two diamonds side-by-side, a dual-track double diamond would look more like this:

In this version, research and execution happen concurrently. There are feedback loops established within and between those two diamonds. Checkpoints such as standups, desk checks, paper prototyping with users,, or demos, function as these feedback loops, with smaller feedback loops occurring at a greater frequency than larger-scale loops. That makes this approach more likely to catch errors early and reduce time developing things you don’t need.

For teams that are smaller or lack resources, dual-track Agile might seem like an aspirational challenge. However, taking the time to adopt this approach and shifting focus to build smaller things might slow the process slightly in the short term but will reduce waste in the longer term. The value of parallelization, tighter feedback loops, and more focused development will yield greater value over time.

Product vision in dual-track Agile

If we return to the idea of the product vision as the hypothesis, in the dual-track Agile paradigm, teams no longer have to wait until a full release cycle is complete to potentially modify the product vision. Anywhere where overlap occurs is a point where the product vision can change. And it should change as the team gains more knowledge, replacing assumptions with data backed by facts.

For a more specific recommendation, I find that reviewing the product vision at the start of every sprint planning session is the most effective point at which to decide whether the vision needs to be modified based on new learning. Sprint planning is when the team is debating or prioritizing different items of work, so the product vision should be agreed upon before that occurs.

Closing the loop

Dual-track Agile is about improving the feedback loop. Releasing software is expensive. Reducing—not eliminating—waste is the critical goal. If you are closely collaborating cross-functionally, you are maximizing the amount of information you can learn within the constraints of resources and goals and reducing waste through that process.