Around 10–15 years, I started working with teams in the ‘product space’ — this reflected a wholesale change in the way that companies built software. The most obvious shift, was a move away from large ‘requirements’ documents and waterfall aproaches to more adaptive methodologies such as Agile and frameworks such as Scrum.

As a result, the teams and team operations, also changed. We moved towards teams with a blend of skills and greater autonomy, focused on building software and digital services for our users and/or customers.

For design, new agile approaches meant not doing ‘big design up front’ during a ‘design’ phase. It was more about aligning our working practices towards making smaller increments, that supported sofrtware delivery using shorter timescales.

Describing it this way, makes it sound like the adoption of agile and design process was pretty straightforward and as we made the move, we had only minor procedural problems to iron out.

However, now 15 years later, with more experience across many more product teams, it’s still challenging to get the right mix of these two practices because as well as the many competing priorities between agile and design, many organisations often incentivise how software is made over what to make.

Aligning two approaches

‘Dual track’ delivery has emerged over the last 5 years to address the competing concerns of design/UX and agile approaches. In a nut-shell, it’s where a design (and design activities) are created ahead of any software delivery. Given its own ‘track’ — it is an approach that tries to ensure benefits are fully understood and features are fully scoped before moving into development.

It’s odd that I am writing about a process that emerged a fair while ago. However, moving countries, I have seen teams in different organisation tackle ‘design’ and ‘delivery’ and this made me realise that many of the issues that emerged with ‘dual track’ are still around.

To that end, I want to talk about my experience with this process and why in almost all cases, companies that adopt ‘dual track’ approaches are almost always ‘feature factories’ — a derogatory terms that refers the the productionisation of sofware that is optimised towards releasing feature after feature rather than solving problems for their customers.

What is dual track?

Dual track refers to the decoupling of two different processes within agile teams, usually the design (or discovery phases) and the development phases. In a scrum context, the ‘design’ phase occurs ahead of the ‘delivery’ phase, in most cases, ‘about 2 sprints ahead’ so that features are ‘discovered’ and refined well before the development teams bring them into production

The expectation is that if design works far enough ahead, and the product backlog is long enough and well groomed, development teams will never be held up in making software. Design completes all necessary research and design work, creates screens and prototypyes, and hands fully specced work over to the development team to build. This way, features will be released continually and these two tracks of design and delivery will be perfectly synchronised and optimised; an orchestrated dance delivering valuable features into the hands of users.

Sounds glorious…

Some orgs love dual track

…and ‘dual track’ looks very attractive to many organisations, because it describes an optimised process where work is fully explored before moving into production. It aims to ensure a steady flow of high quality features and in many organisations(which are incentivised to release software features) any process that optimises this will gain traction.

However, the reality was seldom like the synchronised dance that was described. Organisational incentives often skewed the process, almost always in favour of the ‘development’ track. This meant that outcomes (changes in user behavours that drive business needs) were often never considered. Organistions focused on releasing software, and tended to adopt and favour metrics like ‘velocity’ — that shows the speed of delivery as a numerical point scale.

Dual track feeds into the idea that all developers do is write code

I have seen this born out of the fear of having developers sitting around doing nothing. Dual track approaches seek to mitigates this risk, by making sure there is a robust pipeline of well specified work for developers to pick up and build. Often the ratio of designers to developers is over 10:1, so there are many pressures to ensure that this workforce isn’t idle.

However, this is the unstated cost fallacy of dual track. Organisations want to keep people making stuff because the cost of doing nothing is easy to measure. Metrics of delivery, such as sprint ‘velocity’, are wrangled to represent how much software a team is making.

However, what is not measured is the opportunity cost of making the wrong thing. This is much harder to quantify or qualify. There are often no metrics around the hours spent pushing features into the hands of users that are unused and solve no user needs. And even when these metrics do occur, often coming as the result of major failures, most people in the organisation who advocated this approach are seldom still around to be accountable.

There are often no metrics for the path you should have taken. For this reason, John List In his book 'The Voltage Effect', challenges people and organisations to kill things that aren’t working, as the cost of continuing along a failing path, is not just the sunk-cost of development, but the cost of the missed opportunities and the benefits that coud have been delivered.

In the same way that when we spend our money on one thing we can’t spend it on another, when we spend our time on one thing we can’t spend it on another. When a company focuses all of their resources on scaling one product, they can’t scale another. When a government scales one public program, they don’t scale another. To implement such endeavors means investing not just money but also thousands of hours of time by the people involved. In this manner, as an organization scales, opportunity costs grow—more money is spent, but so is more time. And time, economically speaking, is money

Dual track doesnt accomodate meaningful product discovery

Often the fear of ‘idle’ developers means you can never be far enough ahead on the development track to start doing ‘discovery’. Even if you push for discovery research and prioritising direct contact with your customer, there are often organisational ‘head-winds’ that push you away from the time or space needed for deep generative research. These winds are driven by the bottom line of the percieved waste of an under-utilised development team.

This impact is felt team-wide.

Good user research is a 'team sport' and builds 'product sense' in a team by having everyone involved in research. However, since 'dual track' developers just 'write code' - getting wider team involvement and exposure to user research is considered a waste of time.

The biggest impact, though, is the cost to innovation.

Operating outside the delivery space is vital for innovative ideas to emerge. It’s hard conjure new things and approaches if you are always in the mindset of delivering. Proponents of ‘dual track’ will say that decoupling design and research from development, does give that space.

However, with a Dual track approach, the varying lengths of ‘discovery’ cadence is always the slave of the ‘delivery’ intervals. To give yourself the greatest opportunity for innovation, a 2-week phase-shift is often not enough. Many product people like Terea Torres speak about the postive impact of teams doing continous discovery, how they not only build better products, but build better decision making into the team. This is the benefit of user centricity, the improved decision making that emerges from regular and valuable contact with the people using your product or service.

Dual track pushes an optimisation mindset not a value mindset

In most cases where I have worked, ‘dual track’ approaches are a minature waterfall process, with design executed upfront and thrown over the wall for the programmers to build. Often there is the appearance of collaboration and collegiate working using agile methods, but mostly, those conversation are centred around optimising the delivery process with discussions around the ‘right’ way to groom backlogs, measure velocity and the correct way to write user stories.

All these things though are useful, and necessary. Howeer, if you are doing this with almost zero understanding of your user, without any understanding of whether the thing you are delivering is driving the outcome you want, then you’re in a feature factory.

When does Scrum and Agile work with design?

Rather than just focusing on issues with ‘dual track’ delivery, its worth comparing this with situations where design and agile has worked well. This is when the synchronisation of these process has successfully and consistently delivered working and valuable software to users.

Below are is not a replacement for dual track, but situations and mindsets that emerged in the teams when we focused, collectively, on user outcomes.

1. Improved partnership between Development and Design

A close working partnership between design and development was always characterised by a deep collaboration across the entire design and delivery space. Not just at the points of handover.

This meant that traditional boundaries were blurred and each team member effectively fed into each others work. I have already mentioned the inclusion of developers in direct research with users helped impriove the overall quality of what we made.

For designers, having developers part of our discovery work meant that our tools and approaches also improved. In a quest for better collaboration, our prototyping became increasing sophisticated. Not only did we expand our tool-sets, and explored interactions more deeply , we often prototyped in code. This resulted in higher build quality of our products, reduced bugs and an improvement in the wider product experience..

2. Reduction in documentation

As a by-product, we started to rely less on documentation, with our tools, artefacts and prototypes becoming the ‘source of truth’ for many aspects of the work — from interface elements, behaviours and states. We still used documentation tools (like confluence and Jira) but within those tools, we better integrated the things we made/prototyped/tested so reduced the need for explicit requirements. If you wanted understand how something worked or what it should be, link to the prototype and let’s have a conversation.

3. Shared tools and improved understanding across the team

Greater collaboration was also felt in how we cooperated in product strategy and direction. Our work was not seen as discrete delivery segments, but as steps on the way to a future goal or outcome.

The whole team began to own items such as the product roadmap and collaborated on processes like user story writing, acceptance criteria and definition of done. These became much more customer focused as we were now much more aware of our customers and the benefits and outcomes we were looking to deliver. As a team, we also saw the value in clear, user-centred problem statements, and various mapping tools to help us get clear about the problem we were looking to solve.

‘Dual track’ looks to combine design processes with agile software delivery through offset of the ‘discovery’ and ‘delivery’ phases. I am not here to argue that ‘dual track’ delivery can’t deliver valuable products and services. Many teams have and will continue to do so.

However, in my experience, companies that adopt ‘dual track’ often risk creating more siloes and greater seperation between the two disciplines. The best places I have worked have always been characterised by the collaboration between design, development (and product!), resulting in many unforeseen benefits in working practices that improved the quality of the thing we were making.

For many organisations though, ‘dual track’ approaches are really attractive, as they readily give the appearance of progress, often through the lens of ‘shipping software’. Organisations then adopt metrics that are optimised towards delivery, measures like velocity rather than users needs or behavioural outcomes that show the delivery of user value.

However, becoming good at delivering software, doesn’t mean you’re good at delivering good software. And this is the true risk of ‘dual track’, an over-optimisation mindset. To deliver valuable software, to innovate with your customers, you need a much deeper view of your users, built up over time, with the knowledge spread across the whole team. This is where user research is so important and thy way data and knowledge that comes from research helps inform the improved decision making of the whole team.

As not only will you understand if you’re making the right thing, you will also know that what you’re spending the teams time on, is the right thing to be doing. And that is the biggest risk of productivity with ‘dual track’ approaches, optimising the production of a thing no one needs.

“The biggest risk to productivity is always the same: working on the wrong thing.” — James Clear