Developers initially created agile for other developers. The 17 people who wrote the Agile Manifesto got together to compare their approaches to software development and determine what they could learn from each other.
That discussion did not produce too much info on how to discover the right thing to build.
The general consensus was to identify a role that was responsible for identifying what to build (Product Owner, Onsite customer) and leave it up to them to figure out how to identify what to build.
The end result was inserting a development process with iterative feedback into a broader product development process that did not seem to rely on feedback.
Teams could now deliver iteratively, but their discovery efforts were anything but iterative. In many cases there was no attempt at discovery. Instead, someone handed the team a solution asked them to deliver it “using that agile thing.”
Teams realized it didn’t do them much good to deliver in an iterative fashion if they always worked from a sizable, and continuously growing, backlog.
Teams started looking for ways to incorporate feedback cycles back into their backlog refinement process. The end result was dual-track agile.
What is dual-track agile
Dual-track agile (also known as dual track development) is an attempt to incorporate iterative discovery into existing agile approaches. It allows teams to extend the feedback loop to their decisions about what to build and not build.
When your team uses dual-track agile, the product trio focus a portion of their time doing discovery work. The product trio includes the product manager, product designer and tech lead.
Discovery work consists of quickly learning about the problem you’re trying to solve and your chosen solution. The goal of your discovery work is to learn what you should and should not build in your development efforts.
Concurrently with those discovery efforts, other members of the team iteratively build your solution. The work of the discovery track feeds the work of the delivery track. Likewise, the development track informs and influences the discovery track.
Dual-track agile consists of one team working on two tracks of activities at the same time. The product trio spends a bit of time on discovery activities, but they also get involved in delivery work. You also want to involve your developers in discovery work as their perspective can be invaluable.
Advantages of dual-track agile
With a rigorous discovery track alongside an iterative delivery track you can quickly determine whether an idea moves you closer to your outcome. You can then spend your detailed design work on those backlog items that move your solution in the right direction.
These quick decisions about what to build allow you to avoid delivery work on features that don’t drive your solution forward.
Your short learning cycles during discovery make use of things you learn during your delivery efforts. As a result, you can quickly adjust when you learn something new during delivery.
You also can adjust your discovery work to make sure you pull together the right information for each backlog item. This ensures that your delivery efforts are as efficient as possible.
How to use dual-track agile
To use dual-track agile your team needs to agree on how involved each member of the team is in each track. You’ll also agree on the processes each track uses and how backlog items move from one track to another.
Keep all your work on the same backlog to keep everyone up to speed with what’s happening on both tracks. You’ll also want to visualize the work of both tracks and discuss both tracks in your team’s iterations.
Discovery track
The product manager, product designer and tech lead are the primary team members who work in discovery. Depending on how much discovery they need to do, or what they need to learn. They are likely to involve other members of the team periodically.
In the discovery track you conduct learning iterations to address the four product risks:
Value risk - Will customers buy your product to solve a problem they have
Viability risk - is it worth it for your organization to help customers solve their problem
Usability risk - Will users be able to use your product
Feasibility risk - Can you build the product with the available time, skills and technology
In many cases, your team determines the value and viability risks fairly early in your product launch process. On an ongoing basis, confirm that you’re not introducing any changes to the product that will impact its value and viability.
Most discovery work determines if a backlog item is a necessary piece of the solution and to address any usability and feasibility concerns.
It’s helpful to establish the process you’ll use to perform your discovery work. Include performing the necessary experiments to confirm the backlog item is a necessary part of the solution, confirm its usability and determine its feasibility. Map out the key steps in that process and find a way to visualize those steps using a technique such as the discovery board.
The columns on your discovery board represent the key steps in your discovery process. Those steps should ensure that you make decisions about whether to build the backlog item and any experiments you need to run.
Establish a list of criteria that you’ve the four product risks for the backlog item and properly describe the backlog item. That list is often known as a definition of ready.
Backlog items move across the discovery board in a flow type manner. Some backlog items may require more research and experimentation than others. You want a sufficient number of items that meet the definition of ready when it comes time to pull items for the next iteration.
Delivery track
The full product team is involved in delivery track work but involvement varies for some of the members. Developers, product designers, and QA engineers focus the most on delivery. The product trio’s role is primarily to answer questions and provide context since they spend most of their time performing discovery.
The delivery track starts with backlog items that meet the definition of ready. Delivery finishes once you have a releasable portion of the solution. As with the discovery track, you’ll want to map out the key steps in the process and find a way to visualize those steps using a technique such as the delivery board.
Depending on your definition of ready, you may need to do some detailed design work during the delivery track before you start writing code.
Team interactions in dual-track agile
Dual-track agile impacts how the team interacts. To understand how, let’s take a look at the key interactions look like for a team practicing dual-track agile. We used the typical scrum ceremonies as those are the events that you are most likely familiar with.
Backlog refinement
If you’re using a backlog, your discovery track activity includes getting backlog items ready for the team to deliver. This backlog refinement tends to happen on an ongoing basis rather than in a specific meeting.
It’s helpful to identify someone to own each backlog item through the discovery process. The owner of the backlog item does not perform all the discovery for that backlog item in isolation. Rather they are responsible for making sure that discovery happens and that the right people with the right skill sets are involved.
Have periodic discussions to sequence the items that are queued up for backlog refinement - or discovery in general. It’s best to do this on the same cadence as you plan the content of each delivery iteration.
Sprint planning
Assuming you’re using an agile, sprint based approach to develop your product. At the start of each sprint, conduct a sprint planning discussion where your team will identify what they will work on in that sprint.
When your team works in a dual-track agile setting, make sure that you discuss both discovery and delivery activities during your sprint planning discussion. Jeff Patton suggests the following discussion points for sprint planning in a dual track setting.
Discuss what you want to accomplish during the sprint in terms of sprint goals. Also talk about how the sprint goal relates to the overall outcome you’re trying to reach.
Review the discovery backlog items your team will engage in. Agree on how much time those discovery activities will take.
Identify the backlog items the team will tackle during the sprint.
Give the team a chance to discuss the detail plans of the items identified for the delivery track.
Confirm that everyone agrees to the plan.
The end result of sprint planning is that everyone understands what’s planned for the delivery track and have a good idea of the discovery items that are under consideration next.
Daily standup
Teams often find it helpful to have a quick daily touchpoint to coordinate their activities and keep everyone up to speed. If your team is using a dual agile track approach, a daily touchpoint is especially important because different team members have different areas of focus.
Jeff Patton identified the following daily standup discussion topics for a team using dual-track agile.
Note any news that everyone on the team needs to know.
Discuss delivery work
Discuss work to prepare for the next sprint. This is usually discovery work that’s close to ready.
Discuss discovery work. You leave this topic until last so that people who aren’t directly involved in discovery can get back to work.
Sprint review
At the end of a sprint, you want to give your stakeholders an update on your progress. in sprint this is known as a sprint review. The main purpose of these reviews is to get feedback on the state of the product so you can get some input on what you should do in the following sprint.
When you work in a dual track setting, not only should you review what your team built, but also what you’ve learned from your discovery activities. Jeff Patton suggested the following discussion topics for a sprint review.
Look at the key metrics for your product and confirm that those metrics connect to your organization’s north star metrics.
Review your discovery work. Explain your initial hypothesis, whether it changed and why. You also should describe work you’ve done to understand your problem and solution and walk through any prototypes and experiments. While you do this, explain what you learned.
Review your delivery work. Your stakeholders want to know what you’re going to release and when so you’ll need to keep the discussion at a level of granularity meaningful to stakeholders. That means that you may be talking in broader terms than simply backlog item by backlog item. You’ll also want to explain how the things you completed help you get closer to your desired outcome.
You’re explaining what you’ve done for the purposes of getting feedback on how to proceed next. You shouldn’t view the sprint review as a status report, so don’t feel compelled to talk about velocity. Keep the discussion focused on progress toward outcome rather than trying to quantify output.
Sprint retrospective
The final thing your team should do at the end of a sprint is take some time to reflect on the sprint and identify ways that you can work together more effectively. The outcome of the discussion may include any changes to the way you work in upcoming sprints.
This particular interaction is not too different for a team working in a dual track fashion. One difference you may notice is that you explicitly need to discuss the impact of working in a dual track format on your team.
Jeff Patton suggested the following topics that you’ll want to discuss during your team’s retrospective.
Evaluate your product’s key metrics and how they compare to where you were expecting them to be. Discuss any subjective data and qualitative feedback you’ve received.
Evaluate discovery work and determine what process changes you may need to make.
Evaluate delivery work and determine what process changes you’ll need to make.
Remember, the entire purpose of a retrospective is to give your team a chance to pause, reflect, and adapt your processes to be more effective in the future.
Dual track is a means to an end
Keep in mind that you don’t adopt dual-track agile for the sake of adopting dual-track agile. You adopt dual-track agile because your team gets a benefit from performing discovery simultaneous with delivery. You want to learn at the same time as you deliver parts of your solution.
When you decide to incorporate discovery and delivery you need to make sure that you have the proper skill sets on your team to do that. Your team needs to have the right skill sets available on a dedicated basis to perform discovery. If you don’t have a product designer for each team, or a clearly identified tech lead, you may not be able to do continuous discovery alongside delivery.
You also need to be prepared for your discovery efforts to kill a lot of ideas before they reach consideration for delivery. If you aren’t experiencing that, chances are you aren’t doing discovery correctly.
But if you do have your team staffed properly, and you use discovery to apply focus to what you’re working on, you’ll find your team is much more effective at attaining outcomes than it was in the past.
FAQ
How efficient is dual-track agile
Discovery helps your team focus on the right backlog items by quickly validating ideas and preventing the ones that don’t make sense from getting to development. As a result, dual-track agile is highly effective by virtue of helping you avoid work.
dual-track agile also makes sure that the backlog items that do make it to delivery are described sufficiently such that the team does not spend an inordinate amount of time trying to figure out the backlog item.
What’s the main difference between dual-track agile vs. agile
Agile approaches were initially created in order to address issues that software development teams faced. Most of the approaches are focused on building software right.
dual-track agile incorporates a rigorous discovery activity, so not only does your team build software right, but you also build the right software.
Kent McDonald
Read also
Prioritize with confidence
