The best way to do Dual Track Agile
In this article I examine:
- What is Dual Track Agile and how it is typically implemented.
- What process and mindset issues can arise in typical Dual Track settings.
- How a single Sprint integrates both types of work with better outcomes.
The birth of Dual Track Agile
The idea that requirements cannot be defined effectively before their implementation starts was one of the drivers for the birth of Agile Software development during the 90s. In May 2007, Desiree Sy published an article [1] explaining a new approach to integrate product design activities into the product lifecycle, with lighter design activities interwoven with development ones across the product lifecycle.
Building on that article, product management authors such as Jeff Patton and Marty Cagan spread the Dual Track approach [2] where the product development workflow is divided in two tracks:
- Product Discovery (build the right product) is performed by the Product Manager, Designer and Lead Engineer. Discovery work is managed on one backlog and considered “done” once a feature is considered valuable and feasible.
- Product Delivery (build the product right) is performed by the development team and managed on another backlog, once the Product Discovery backlog considers the features “ready to be developed”.
While the original Dual Track concept [4] coined by Jeff Patton meant to be done in a single team with a single backlog, the most common approach to implement it has been to split them.
In my experience, the Dual Track concept is now commonly associated to the split teams and backlog approach, so I propose to avoid this term from now on.
Typical Dual Track Agile issues
Dual Track Agile provides a continuous discovery and delivery approach which makes sense and creates focus. Teams focus on “discovering” only features with top priority, removing waste for requirements that may not find its way into the product. Developers avoid frustration working on features that may change or get stuck during the Sprint. However, this model also shows weaknesses, such as:
1) Long validation cycles of features. A discovery Sprint tries to “validate” features by doing user research (is this feature really needed?) and UX/UI design [3] (e.g. mockups), but empirical validation is obtained when the product is tested with real users and technology. That means that on a 2 week Sprint cycle, defining, developing and validating features with real data can take up to 6 weeks. If the validation fails, the cycle time can jump up to 12 weeks. Integrated discovery and delivery Sprints may have a shorter cycle time.
2) Poor usage of Sprint goals and Product Backlog transparency. Scrum promotes a single transparent Product Backlog so all stakeholders can contribute to inspection and adaptation. With the separate Backlogs model, contributing to Product Discovery is difficult for the Development Team. Besides that, the “development” Sprint goal can be at best an umbrella for set of Product Backlog Items (PBI) to be developed. The Sprint Backlog contains “validated” PBI so the uncertainty of the Sprint is low and the Sprint Goal loses the purpose of setting a challenge where the team can creatively come up with a solution.
3) Disengaged developers. Since most of the functional decisions for the items have been already taken, the Development Team may feel as a “feature factory”. They don’t have much space for contributing to the product functional design, and therefore may have less feeling of accountability over the customer outcome. That can make them feel disengaged from the product success.
4) Less learning. Discovery and delivery can become functional silos, even if a Lead Developer participates in discovery activities, and the Product Manager collaborates in the Sprint events. Everybody can contribute with good ideas, but splitting discovery and delivere Sprints can reduce creativity and learning.
Todd Lankford expresses this beautifully in his article [5]. I especially like his explanation how Dual Track can produce all the 7 types of Lean waste sources.
Integrating discovery and delivery teams
Integrating discovery team members into the delivery team is conceptually easy. However some real-world problems may appear when trying to do so, e.g.:
1) There may beonly one designer for several teams. A designer hopping between teams can make the collaboration more effective, but at the same time be less productive due to context switching. Promoting transparency in the teams’ Sprint backlogs and the shared planning of work can keep the designer’s productivity high enough.
2) Designers may feel disconnected from the Sprint events. A designer may think most of the discussions within events are none of her business and consequently feel that those are a waste of time. This feeling can increase if the designer needs to attend the Sprint events of several teams. Even if some parts of the Sprint events are not fully significant for the designer, a Scrum Master can help her to reveal how coordination and shared understanding with the developers improves when she is present at events, and thus how design-related rework drops.
Do Scrum Teams need a dedicated designer? Lean UX author Jeff Gothelf answers “yes” to that question [7]. Effective involvement and coordination during the Sprint is difficult if the designer is outside the team, and even harder if the designer is outside the company.
Integrating discovery and delivery work on a unified Product Backlog and Sprints
Managing discovery and delivery types of work in a single Product Backlog is also easy. A PBI is any work package that delivers value, whether a request, need, idea or user story.
The integrated team needs a unified board and workflow to manage both types of work: upstream (discovery) and also downstream (delivery).
The hardest thing to do is to fit some discovery activities into short Sprints. While some activities are quick (e.g. creating a wire-frame), some others need to span several sprints (e.g. user research or data collection). Avoiding “undone” work at the end of the Sprint is one of the basic principles in Scrum to get fast feedback. However, having some discovery work spanning several Sprints shouldn’t impact the Sprint feedback loop as long as that work is not part of the Sprint goal.
If you want to learn more about how to integrate Discovery and Delivery work, you are invited to attend one Professional Scrum with UX workshop.
Feedback wanted!
What are you biggest challenges integrating Product Discovery into Scrum? Did you find any valuable advise in this article? I would love to read your opinions.
To lean more…
- Adapting Usability Investigations for Agile User-Centered Design | Dessiré Sy
- Dual Track Agile | Marty Cagan
- UX Design Defined | uxdesign.com
- Dual Track is not Duel Track | Jeff Patton
- We Need One Complete Product Team | Todd Lankfort
- Here is how UX Design Integrates with Agile and Scrum | Jeff Gothelf
- 5 Rules for Integrating UX with Agile and Scrum | Jeff Gothelf
