Intro to Dual-Track Agile

Rob Sanchez

When implementing Agile methodologies for software teams, there are many different obstacles that can come up. One of the big ones is when the value delivered for a release doesn’t align with user needs or expectations, this is typically paired with a slowed down release frequency too. This can be small at first and eventually snowball into an avalanche of inefficiency if left unattended. One method to deal with this and many other issues that can arise is Dual-Track Agile. Dual-Track Agile is happening in some shops without the name and process but completely absent from many others. Like everything Agile, the Dual-Track variety is a framework; these are meant to be used as starting points for agility and can always be adapted to suit the business. Dual-Track Agile can contribute to improved Product innovation, decreased defect rates, optimized dev processes and much more. But how can companies begin to adopt it? Let’s dig in.

Dual-Track Agile was first explained in Jeff Patton’s book, Story Mapping, and later expanded on in Marty Cagan’s book, Inspired: How to Create Products Customers Love. The premise here is to adopt a two track method with one track for Discovery and another for Delivery. These run in parallel and allow Delivery to be informed by Discovery, which is informed by customer interviews/feedback, data analytics, market research and internal/external stakeholder pressures. A feedback loop is created where the two tracks interact with and advise one another, which connects teams and starts solving problems by bringing the innovation triangle of Dev, Design & Product closer together.

The Delivery track is good ol’ Scrum/Agile essentially unchanged where sprints are planned containing the work to be done, and the team regularly reviews its progress and processes via retrospectives. The Discovery track attempts to formalize some Product Owner concepts as business processes. For organizations with Product Owners, they’ll be leading big pieces of the Discovery track, and for those without, your Product Manager, BA or similar role will lead these. Activities on the Delivery track include getting user feedback via interviews and surveys like NPS, creating prototypes and conducting user testing to confirm ideas and solve real problems. Development should be considered as stakeholders for the Discovery track to get that feedback loop really going.

The way this works is imagine we have a Dev team sprinting away, and one of our lovely customers has an issue with the product as they tend to. Our BA/Product Manager/Product Owner hears about this and works directly with the customer to discover that an existing feature is not solving the customer's problem. Now, there’s a decision to be made: should we make the change or find a work around/say no to the customer? In Product, we always want the former, to solve all of the problems our customers have and perfect the software we work on. But this can be curtailed hard by budget, culture, process and everything else that makes up our world of work.

Dual-Track makes the decision much easier, instead of saying no or yes at this point the Discovery team including BA, Product Owner/Manager, Design, Internal Stakeholders can work to fully understand the problem and prototype a change or new feature using Figma or similar solutions. Then, Dev is brought in to weigh in on the design. With their knowledge of the underpinnings of the application, this is really where innovation can happen. Ultimately, we can test ideas this way by prototyping changes quickly and getting good feedback. This allows teams to gather all of the Product requirements needed and write great acceptance criteria. Few things will slow value delivery like poorly written acceptance criteria.

There are many ways to implement this as it really depends on the current state of your organization. Always start by reconfirming the vision and overall Product goals. Consider using an Agile Liftoff meeting to align the company and teams involved. Next, start to explore different Discovery activities to formalize the Discovery process. If the Dev teams are already sprinting, they can wrap things up and your next sprint should include some items defined by the Discovery teams. The main output of the Discovery track is well defined epics/user stories that accurately meet user needs and deliver value for the business. This can be easier said than done, but remember continuous improvement here and use retrospectives for both teams to keep things improving.

A culture of collaboration and psychological safety is important here to encourage the members of both tracks to speak up and contribute to innovation and feedback. Discovery activities include user interviews, stakeholder interviews, defining user personas, prototyping ideas, getting Dev/user/stakeholder feedback on prototypes, defining epics and user stories with excellent acceptance criteria and establishing metrics and KPIs to track progress and measure success.

I’ve focused more on the Discovery track, because that’s the additional piece added. Standard Agile covers the Delivery track but still deserves some attention in this process. Delivery teams have to adapt and begin actively providing feedback in prototyping sessions. They know how possible it is to build features and can reign in wild or time consuming ideas before they get out of control. This also helps Dev to understand the things they’re building, uniting the vision of both tracks. Delivery teams can improve this process by buckling down on good Agile methods like reviewing user stories and acceptance criteria thoroughly before starting and working to reduce cycle time and other aspects of value delivery.

We’ve only skimmed the surface of this method today as much can be said on how to roll-out and maintain both tracks. In general, the Discovery track is a formalized version of Product Owner responsibilities and involves Design, Product, stakeholders and most importantly users. In Dual Track-Agile, the Delivery team is informed by the Discovery team. Without good user feedback, it’s hard to measure value and make sure to include users in the process. The goal here is to shrink the triangle of innovation on your teams so Dev, Design and Product work closely and collaboratively to create value for the business. Explore different Discovery activities and prototype ideas quickly with Dev feedback to confirm that you're solving user problems with the work being done. Stay Agile.