Many organisations today struggle to build products and features that their customers would actually need and use. In the product space, there are a myriad of concepts, frameworks and experimentation techniques that are supposed to help you create cross-functional product teams and enable them to discover both what to build and how to build it.
Even after choosing a suitable technique, companies still tend to struggle with balancing discovery and development when they are limited by time, budget or people.
This blog post focuses on the Dual-Track Agile model, which can help you reconcile discovery and development processes. Having been implementing it and seeing how it works in practice for several years now, I am going to comment on Dual-Track Agile’s capabilities of helping you balance the two in a series of blog posts.
Today, I am going to take a theoretical look at the model, its benefits and the challenges of using it. In later articles, I am going to go into detail about the practical implementation, where I am going to share my experience with applying it with teams I have worked with.
What Is Dual-Track Agile as a Concept?
Although it has become very popular in recent days as ‘Dual-Track Agile’, the concept in its essence is definitely not new. In fact, the first reference to it appears a few years after the release and popularisation of the Manifesto for Agile Development itself. The person to make this reference is Lynn Miller, Director of User Interface Development at that time, who presents her “Case Study of Customer Input For a Successful Product” at the Agile Development Conference, where she speaks about “interconnected parallel design and development tracks”.
Many people helped to define and later develop what we call Dual-Track Agile today. Miller was followed by Desirée Sy and her cornerstone work “Adapting Usability Investigations for Agile User-Centered Design” that referenced separate design and development tracks that were meant to unfold in parallel.
In 2021, Marty Cagan and Jeff Patton formed the notion of “dual-track scrum” that would very much resemble Dual-Track Agile, where the outputs of discovery are the inputs of delivery.
According to Cagan:
The ‘Dual-track’ model shows the parallel tracks of discovery and development throughout the product design and delivery process. These continually feedback into each other informing new hypotheses.
It can be represented as something like:
As you can see, the model involves two tracks with different phases that go simultaneously. The idea is that your team will work on discovery track initiatives to define the hypotheses to be discovered, come up with experiments to test them, measure what the outcomes are and learn from them. Essentially, this will result in proving or disproving the hypotheses your team started with.
At the same time, you can apply what you have learnt when you form your backlog of development work to be done, build it, measure it through things like user feedback and learn from your findings. The final learnings can inform new hypotheses to be put back into the discovery track. Essentially, the discovery track would determine what should be built, while the development (aka delivery) track would determine how to build it.
In order to understand the benefits and challenges of using this model, let us look at the context of the type of organisations and environments I have seen Dual-Track Agile applied in and the reasons it has helped. That is not to say the model will work regardless of context, so it is up to you to decide if you have similar organisational context or pain points and feel this model will address them.
One of the companies I worked with was a fintech start up and the other was a healthcare scale-up. Both of them worked in very fast-paced environments, they were very competitive and felt the pressure of having to continuously learn and innovate so they could stay competitive in their respective markets.
Both organisations were going through investment rounds, so they needed to stay on top of the sorts of initiatives, products or features they should invest in. That could help them get buy-in from their investors which naturally they needed in order to stay afloat.
Although the products the two organisations were looking to build were vastly different, they both had a very vast product space and the product folks were struggling to manage that. There were many unknowns but one of the major ones was if the features and the ideas they had about the product itself would actually get a return on investment after all.
Having given you the context, let us explore the benefits and challenges of applying the model itself.
What Are the Main Benefits of Using Dual-Track Agile with Discovery and Development Tracks?
1. Managing a vast product space
If we take the example of the fintech start-up, there were many product paths they could have gone down – anything from e-wallets, through peer-to-peer lending to prepaid card solutions.
They would find it really hard to narrow down the actual product or feature that they wanted to invest in. In other words, they could not pinpoint the customer need they wanted to solve. In this case, the Dual-Track model provided a systematic way of checking assumptions, running experiments and proving/disproving our hypotheses fast.
Similarly, this model helped the healthcare scale-up to manage the vast product space but not because there were too many other companies operating in the exact same space. The company was pioneering in the digital healthcare space and needed a way to find out which product/feature was worth investing in and do it quickly. Since the product and services they offered were unique, there was not much research done in that specific market place.
2. Team comms & user/stakeholder involvement
Applying the Dual-Track model would also help with team communication as well as user and stakeholder involvement. Usually, best practice teaches us that we work in cross-functional product teams where people can get involved in different activities, see the full picture and get to collaborate. In practice, however, sometimes we still create silos around our specific role.
We should keep in mind that getting people to collaborate and communicate does not always come naturally to them. Most people will fall into what I call, their ‘role routine’ where say developers or testers will focus more on the building and implementation side of things, whereas designers will focus on the research and discovery side of things.
This all makes sense given the role and responsibilities those people have on a team, however, oftentimes I see how people remain isolated and even ignorant to anything but their core role focus, which diminishes the value of having a cross-functional team in the first place.
In that sense, by having the two tracks being owned by the whole team, you encourage people to get involved in activities they usually would not be included in. These might include product evolution conversations, product analysis or user research.
Overall, this creates a very collaborative environment not only within the team but also with users and stakeholders. In my experience, it contributed to greater knowledge sharing and alignment among team members, who showed higher motivation because they were aware of the reasoning behind the requirements. Furthermore, connecting the customers, the business and the development team helped the latter empathise more with the customer needs and understand the core problem earlier on.
3. Stakeholder management
One aspect I did not anticipate the Dual-Track model to help with was stakeholder management. In both organisations I have seen the model applied, there were many stakeholders whose opinions on what should be built and how it should be built tended to differ. There were too many choices and unverified assumptions that could not be systematically proven and therefore prioritised.
Introducing the discovery track in that context helped do exactly that. It made it possible for stakeholders to get directly involved in experiments that the teams would run. They could see their ideas being tested and find out what the learnings from those were. That empowered a decision making process about what should be built, parked or investigated further.
4. Accelerated delivery (of the right thing)
Ultimately all of the above resulted in accelerated delivery of the right thing because there was less wasted effort of focusing on something that was ultimately not going to provide that much value for the customer.
5. Lower development cost
That in itself lowered development costs as the teams were focusing on building those products and features that were deemed more valuable to customers.
Dual-Track Agile is a model aimed at reconciling discovery and development processes. It can help shorten delivery time, facilitate stakeholder management, improve team comms, help navigate the product space and finally lower costs.
In the following articles, we are going to see how to apply Dual-Track Agile and learn more about dealing with potential challenges.
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.