Skip to content 
Welcome to Part II of the Infinite Lambda’s blog series on Dual-Track Agile. You might want to check Part I that explains what this model is and looks at the benefits of applying it. Today, we are going to focus on the challenges of using Dual-Track Agile and offer strategies to overcome them.
There are a number of challenges that teams and organisations face when they decide to apply Dual-Track Agile in practice. In this article, let us explore the main challenges that delivery leads for tech projects might experience and look at efficient ways to address them.
In the context of this article, we will be using the terms development and delivery interchangeably.
1. Team split for development vs discovery
The first challenge of Dual-Track Agile relates to the notion of splitting the team into 2 parts, one focusing on delivery while the other focuses on discovery. In fact, some organisations do apply Dual-Track Agile exactly this way. However, that is intrinsically not the point of the model per see.
This model requires ONE team that owns both of the tracks of delivery and discovery. That said, even when there is one cross-functional team, you could still experience a split. That is because in practice you would always have some people (and roles) that are naturally more involved in the discovery process and others that are more involved in the development ones.
It mainly depends on the responsibilities and specifics of the roles in the team. For example, design and product related roles would naturally be more involved in the discovery track, whereas developers would be more involved in the development track.
One way to overcome this is having the so-called bridging role. This is usually a business analyst, a product manager/owner or an (UX) product designer. Apart from their usual responsibilities, this person would make sure the two tracks go in parallel, sync up on activities and make sure there is alignment across the whole team and not only within a single track of work.
2. Timeboxing discovery activities
Another challenge could be timeboxing the discovery activities themselves. This could stem from the fact that it could prove hard to answer the question ‘At what point have you learned enough about something?’ In fact, is there ever a time when you learn enough or do you just decide it is time to move on to learning something new?
Those questions are very difficult to answer in practice, which directly affects timeboxing habits and may contribute to ambiguity.
One of the ways this can be resolved is by timeboxing discovery activities on a weekly basis, ending up with one or two experiments of the week all the time. This would allow the team to focus their discovery efforts on a new hypothesis every week.
At the start of each week, the team would choose one of the prioritised hypotheses, brainstorm proving/disproving approaches and choose specific experiments to run. By the end of the week, there would be an outcome to share.
This approach helps keep experiments in the discovery track low-cost timewise (with each experiment costing a week’s time) and see activities moving week by week.
3. Making a call: build it, kill it or keep learning
The biggest challenge hands down is making a call whether you should build something (i.e. progress to the delivery track), kill it or keep learning about it.
This challenge stems from the fact that the items you have in discovery should not always make it to delivery. The beauty of having two tracks lies in having them run simultaneously, so you can decide what is worth building next and it provides the biggest value to pursue.
You will continuously need to make a decision on what moves to development. A weekly cadence of hypothesis proving and disproving means this choice will be due every single week.
4. Prioritising discovery items can be tricky - ‘How to predict what you need to learn next?’
How do you predict what you need to learn next? Prioritising is extremely important and just as difficult to do during the delivery of any piece of work. That is why there are numerous tools, frameworks and approaches available to support that activity.
It is no surprise, however, that prioritising discovery items can be even harder because as a team you will need to keep asking yourselves what you need to learn about next.
Organisations tackle this particular challenge in different ways and experiment with various approaches to find what works best for them. Here are two examples that practice shows to be highly efficient:
- Prioritisation matrix
The prioritisation matrix has you map out all activities and discovery hypotheses you have and be realistic on whether they are aligned to the organisation’s short, medium and long-term goals.
If we deemed a hypothesis was linked to a short-term goal and is high value, then that would be prioritised next. This is what it looks like in practice:
- Value canvas to assess priority levels
Alternatively, you can opt for a lightweight value canvas where you go through a process of defining the priority level of a set of hypotheses.
The way this is done is: you have a set of categories you assess your hypotheses against and each hypothesis gets a certain score per category. The sum of all the points a hypothesis gets is its total priority level, which ultimately determines how valuable it would be for the team (and organisation) to prioritise it. Once you know how valuable a hypothesis is related to other hypotheses, you can decide on the experiments that stem from it.
The categories you evaluate your hypotheses against are:
5. Delivery pressure
Finally, in every project there comes a time when delivery pressure is high enough to affect prioritisation. That could stem from any number of factors, such as external dependency to do with regulation or compliance, sales goals, internal initiative related priorities, etc.
Even for projects with no set hard date to observe, there are always factors for you to consider, which is why you need to come up with a timeline for completing a piece of work.
It only feels natural that in times of high delivery pressure, you switch focus to the development track in order to be able to meet your deadlines. But it also tends to be challenging to go back to the discovery track and do the two in parallel.
Here said bridging role comes into play again. Having such a role helps keep the team honest and clear on what is prioritised and why.
For instance, your team might agree to focus solely on development for a few iterations in order to deliver an important feature to the business and limit distractions in the process. Once this is completed, there has to be a person to ask the question whether it is the right time to pick up discovery again and switch back to running the two tracks in parallel.
Make sure you also check out Part I of this series "What Is Dual-Track Agile and What Are The Benefits of Using It?".
About the author:
Adriana Katrandzhieva is a Senior Agile Delivery Lead at Infinite Lambda. She has worked as a business analyst, product manager, delivery lead and Agile Coach/Scrum Master at a series of consultancies in the UK, Germany and Bulgaria, having worked with a variety of clients in finance, healthcare, commerce and mobility.
