In this guide, we’ll give an overview of dual-track agile, including its origins, principles, and how the framework has evolved in the context of the continuous discovery.
We’ll also highlight some key distinctions between dual-track agile and continuous discovery and recommend some further reading if you want to learn more about these concepts straight from the source.
Table of contents
- What is dual-track agile?
- Continuous discovery is the new dual-track agile
- What’s the difference between dual-track agile and continuous discovery?
What is dual-track agile?
In the early days of agile, teams were still struggling with waterfall-like ticket-taking relationships. Design would be expected to do upfront work and then hand off their plans to product or engineering. Likewise, product managers struggled to include the entire team in their planning and prioritization work.
The heart of dual-track agile (also called dual-track scrum or dual-track development) is about integrating discovery efforts (determining what to build) with delivery efforts (building) and fostering close collaboration across product, engineering, and design. All of this is to maximize the delivery of valuable outcomes to the business and customers.
Dual-track agile is really just agile. The label dual-track agile causes confusion.
For example, the most common misconception associated with dual-track agile is that there are two separate teams for discovery and delivery or separate people with different responsibilities. This was never the intention.
Jeff Patton’s series of articles from 2017 to 2019 address dual-track agile myths and share practical tips for product teams.
Continuous discovery is the new dual-track agile
If you’re interested in dual-track agile, you need to know that this general idea has evolved and improved vastly since the term was first coined more than a decade ago. In fact, continuous discovery has essentially replaced dual-track agile over the last couple of years.
Let’s take a quick look at the origins of dual-track agile and what this looks like today in an ideal digital product development setting.
Dual-track agile: A brief history
A couple of years after the Agile Manifesto was created, the Journal of Usability Studies published a paper titled “Adapting Usability Investigations for Agile User-centered Design,” which described UX and engineering working collaboratively across “dual tracks” or “parallel tracks.”
Indeed, designers and developers working so closely together was a novel concept at the time and a helpful contribution to the agile community, but these were essentially mini-waterfall handoffs between separate teams. We have much better ways of working today.
A few years later, sometime around 2012, between some talks and articles, Jeff Patton and Marty Cagan, esteemed thought leaders in the product management world, coined the terms dual-track scrum and dual-track agile. Later that year, Cagan began musing about the idea of continuous discovery following the rise of continuous delivery in the agile and DevOps world.
The story didn’t end in 2012, however. A designer-turned-product-leader named Teresa Torres worked with product teams from a wide range of companies for eight years before releasing the groundbreaking book, Continuous Discovery Habits in May 2021. This book has a forward written by Marty Cagan and dishes on everything you need to know about the inseparable nature of discovery and delivery, as well as the critical, triune relationship between design, product management, and engineering.
What is continuous discovery?
Continuous discovery aims to help product teams build the right things right and quickly test assumptions to reduce waste and mitigate the risk of building the wrong thing.
Continuous discovery as a process first expects a “product trio,” which consists of three individuals from design, product, and engineering, to be in place. Other key experts should be included as needed.
This group works together as one team, understanding the current experience, target customer segment, and business objective. They work together to interview customers, analyze data, and synthesize findings while constructing a living, visual breakdown of the opportunity space. Opportunities are the needs, pain points, or desires of the target customer.
Even aside from the book, Teresa and the team at Product Talk have tons of resources available if you want to learn more about continuous discovery and related concepts.
What’s the difference between dual-track agile and continuous discovery?
There are at least three notable differences between the old dual-track agile and the newer continuous discovery concept. These differences have to do with customers, the discovery-delivery relationship, and the triad team of design, product, and engineering.
First, the emphasis on talking with customers is the starkest change from traditional dual-track agile. It’s not that dual-track agile was anti-customer — far form it — but the emphasis in this topic was always more on the relationships of the different functions and how the individuals work together within the set agile frameworks, such as scrum.
In contrast, as Teresa Torres prescribes, customer interviews are by far the primary source of insight into opportunities to move any metric a team is aiming for. Much of her book covers how to conduct customer interviews and automate these processes. User research often dominates the interview discussions as well.
The next obvious difference in the evolution from dual-track agile to continuous delivery is simply how we think of these two types of work.
In an article titled “Dual Track Development is not Duel Track,” Jeff Patton wrote, “There are two kinds of work, and there’s no way around it.” He also says later in the article, “Discovery and development are shown in two tracks because they’re two kinds of work, and two kinds of thinking.”
In contrast, Teresa Torres clearly sees discovery and delivery as intertwined. Here’s a snippet from an interview with Torres on the Product Coffee podcast:
“I think when you get really good at continuous discovery, there is no longer a distinction between discovery and delivery… It’s just a thing we are doing. I don’t need to put a label on it or call it a track or call it a phase. It’s just something I am always doing… In our early rounds of assumption testing, we might be doing prototypes and surveys and data mining, but in our successive rounds [of discovery] we’re probably doing live production tests. A live production test requires delivery…”
In Chapter 11 of the Continuous Discovery Habits book — which I am happy to say I own and cherish — Teresa writes: “. . . we say discovery feeds delivery and delivery feeds discovery. They aren’t two distinct phases. You can’t have one without the other.”
The trio: Design, product, and engineering
Although not incompatible with the old ways of dual-track agile, continuous discovery really hits hard on the specific working model of product, design, and engineering. This product trio is also referred to as a triad or trinity.
The product trio is exactly three individuals dedicated to a goal and opportunity space. This is an inclusive group, however, so others can be added as needed, depending on the opportunities being explored. Add in the rest of the development team and you have a standard Marty Cagan product team or squad.
Just to illustrate how big of a deal this is in continuous discovery, Teresa Torres has said that her company would not even entertain a consulting gig if the prospective client does not already use trios.
Go do continuous discovery!
Before you dismiss continuous discovery or dual-track agile, I’ll leave you with another quote from an interview with Teresa Torres on Rocketship.fm:
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
“There’s a million reasons why you can’t work this way, but the reality is, the best teams do work this way. So . . . ask yourself how much you want to be one of those best teams. And if the answer is you really do want to be one of those best teams, then you gotta start chipping away at those obstacles . . . This is how products are being built today. It’s how the best products are gonna continue to be built in the future.”