How to Apply Dual-Track Agile in Practice

This article is a part of a series on the Dual-Track model. Here, I am going to share with you 5 rules on how to apply Dual-Track Agile. These will help you get the full benefits of using the model and tackle the main challenges associated with it.

1. Team ceremonies to cover each or both tracks

Just like in an usual one-track development process, with Dual-Track you have stand-ups or daily scrums, frequent sessions regarding items progress and execution. The difference is that here you have these for both tracks.

There are a few options to go about this. On the one hand, you can experiment to have one stand up to cover both tracks, which might get too long and unproductive. If this is the case, you can split the session and have a separate standup for development and discovery.

It is worth noting that you might not need a discovery standup every single day and you can opt for quick updates two or three times a week. For example, in one of the teams where I applied Dual-Track, we found it was better to split the activities, leading to more focused discussions and ultimately saving time.

At some point, we also added a 30-minute discovery roadmap session or what-is-next-to-discover that we would hold each Friday. That helped us prioritise and assign the tasks for the following week in a more efficient way.

Team ceremonies dual-track agile

2. Measures of success for each track

Discovery tasks should be treated the same way you treat your stories or tickets. Their content would be different but they all need to be prioritised against the value they deliver or according to some specific sequence that makes sense for your project/initiative.

Both types of tasks need to have some sort of measurement of their success with clear KPIs and acceptance criteria. This is even more valid for discovery tasks as their nature is a bit more fluid and harder to define.

Teams tend to struggle to define the measures of success or the way to prioritise them at first but there are various popular techniques to help you do that.

Pro tip: Map the items on an importance vs effort matrix. You can also enrich the prioritisation approach by having additional categories for your discovery hypotheses.

This will allow you to make sure the hypotheses are aligned to company goals, to the initiatives you prioritised as well as to the KPIs.

Consider using the following template:

hypotheses priority

3. Shared team responsibility

In the Dual-Track Agile model, it is essential that the whole team owns both tracks. Of course, some roles within the team will focus more on one of the tracks. For instance, the tech lead will mainly drive development, while the product owner, the business analyst or the designer will be more involved in discovery. That said, the success of both tracks depends on the whole team, which makes it the whole team’s responsibility.

4. Frequent playbacks to others on each hypothesis

It is pivotal that you hold frequent demos of the work the teams have completed in a sprint or iteration that cover both tracks. You can have a development segment where you demo the software that has been built and that is to be built. However, you also need a discovery segment that includes the hypotheses you have tested and the learnings from those experiments.

Pro tip: have an experiment of the week and make sure you share how it has gone and what key results you have drawn. This will help you define where you should go next with discovery in general. It also works wonders in terms of ensuring everyone is on top of developments. On the one hand, it will keep your stakeholders informed on what has been going on in either track. On the other hand, it will come handy as a neat way to play back to each other various activities people were involved in within the last couple of weeks.

5. Having a definition of ‘done’ is equally important for both tracks

Having a definition of done is a must for development tasks. Here, ‘done’ might mean the software is implemented or tested, or that it is in the development, staging or production environment.

Similarly, for discovery related tasks, you need to know when a hypothesis has been proven or disproven, so that you know what to do with a specific idea. For each idea, decide how you would like to proceed:

  • Continue learning about it: you will execute more experiments and invest more in related hypotheses about that idea;
  • Proceed to development track: you have learnt enough and you want to take the idea or hypothesis to development;
  • Bin it: if the idea is not worth building at that stage, bin the idea;
  • Park it: this is what you do if you do not want to bin the item just yet but you do not have concrete outcomes to prove it is worth building either. As your roadmaps develop over time, there might be a number of parked ideas that you can go back to and choose to explore in the future.

definition of done

These are the essential items to keep in mind regarding the application of Dual-Track Agile. I have seen the model applied in different teams with their own roadmaps and organisational goals but these rules have invariably helped to keep both tracks moving forward and ensure efficiency.

This blog post is Part III of a series dedicated to Dual-Track Agile. Make sure you also check out Part I that explains what the model is and covers the main benefits of using it. Part II elaborates on the challenges of applying the model and offers efficient ways to address them. Stay tuned for Part IV where we are going to explore several myths about applying the methodology.

More on the topic