In today’s digital world, it’s important for designers and developers to work closely. The dual-track development model helps with this. Think of it like two trains running side by side on different tracks, but going in the same direction. This way, designers can focus on how things look and behave from a user perspective (we build the right things), and developers can make sure they work well (we build the things right).
By using this model, teams can work better together and create great products. This article will explain how dual track works and why it’s helpful.
What is the dual-track model
The dual-track development model was first introduced by Jeff Patton in this article. Patton is also the author of the book “User Story Mapping”. Another must-read for any agilist who wants to improve in Agile for product development.
Dual-track development combines the discovery and delivery cycles working in parallel within the same team. While the delivery track is building the product, the discovery track is already working on the next (possible) features. They are not sequential phases but two sides of the same coin.
The discovery track
In the Discovery track, the goal is to figure out what should be built next. This may involve research, design, and prototype testing activities. Teams are focused on validating ideas and solutions before they are sent to the delivery track.
The purpose of the discovery track is to minimize the risk of building the wrong thing. You can imagine this track as continuously filling the backlog with refined and validated stories. The user feedback is essential to orient the decisions here. The focus is on learning and adapting based on these learnings.
Build-measure-learn cycle diagram popularized by Eric Ries in his book “The Lean Startup”.
The delivery track
On the other hand, teams are working on building and delivering the product increments in the delivery track. This involves software development practices such as coding, testing, and deploying.
The delivery track uses the validated stories from the discovery track and builds on them. The focus is on execution and efficiency.
Scrum Cycle diagram
For those not familiar with the Scrum framework, let me introduce the diagram below that shows the typical Scrum cycle.
The Scrum cycle starts with the Sprint Planning meeting where the team decides the work to be done during the sprint (iteration) according to the ideas in the Product Backlog, the priorities of those items, and the expected team’s capacity for that period. The progress of that plan is inspected and adapted during the daily meetings known as Daily Scrum. At the end of the sprint, the team should have produced a Product Increment, which is reviewed during the Sprint Review meeting. That is also feedback for the next cycle.
Dual-track combined in a typical Scrum sprint
Jeff Patton does not prescribe using Scrum, but it is so common that it works fine for this explanation. The overall idea is to have both tracks working in parallel.
This diagram below is a free adaptation of the original diagram by Jeff Patton to clarify how the discovery conducted during the current sprint (Sprint N) informs the backlog for the development work during the next sprint (Sprint N+1). Click on the image if you need to read the details.
Free adaptation of Jeff Patton’s dual track representation.
You can have specialists in each track, like product designers in the discovery track or software engineers in the delivery track, and they can even have separated backlogs for better workload management, but they are the same team: share the same goals. It’s important to remember that this is a framework and it can be adjusted to meet the specific needs of your product development team. For example, smaller teams might find that the same people are needed on both tracks, while larger teams might have dedicated teams for each one. It is crucial, however, to remain vigilant to prevent the formation of isolated silos.
Differences with the original dual-track model
This is the original diagram that Patton uses in his article and training:
Patton’s original diagram that can be found in his article mentioned earlier.
There are two main differences with my previous diagram that I’d like to clarify:
- I describe some synchronization between discovery and delivery, while Patton draws them asynchronous. From my perspective, it’s often more practical to leverage the regular rhythm provided by the sprints. This allows teams to review, adjust, and continually remind themselves that they are a unified team, working towards the same objectives.
- Patton writes “Release, measure, learn” at the end of the development cycles while I explain the discovery track as a continuous build-measure-learn loop. We’re not saying different things. He is emphasizing the importance of collecting feedback from the software we put into production. I couldn’t agree more. I simply didn’t want to make the diagram more complicated.
Bibliography
- Jeff Patton’s article: Dual Track Development is not Duel Track – We help you create successful product culture and process
- The Lean Startup, by Eric Ries (2011)
The icons used for the diagrams are from Flaticon.com
Also thanks to Isabel Correcher for her feedback on the diagrams used to illustrate this article.
