Daily, thousands of designers around the world start or join new projects. Despite this, unwillingly or sometimes unknowingly, we are forced to choose the process or method that exhausts the team and ourselves. In addition, of course, let’s not forget the fact this often means that we don’t deliver products as we originally anticipated.

This article aims to champion the need for a combined method of Design Thinking and the Dual-Track Agile methodology that supports huge numbers of creatives working across a diverse portfolio of product and service propositions for over two decades.

Disclaimer: As the topic itself could have several different interpretations, I reserve the right to only present the experiences and findings that have impacted on products and services I’ve delivered with my teams.

What is Design Thinking?

MIT Solan Educations offers the course of design thinking breaking the method in 10 independent syllables — here. Ideo U offers the foundation in service design thinking — here. The one who really describes what do you get out of it is Interaction Design Foundation — here.

“Design thinking begins with skills designers have learned over many decades in their quest to match human needs with available technical resources within the practical constraints of the business. By integrating what is desirable from a human point of view with what is technologically feasible and economically viable, designers have been able to create the products we enjoy today. Design thinking takes the next step, which is to put these tools into the hands of people who may have never thought of themselves as designers and apply them to a vastly greater range of problems.”

– Tim Brown, Change by Design, Introduction

You might now wonder how this all fits into Agile-based delivery. For me, it was an integration of the Design Thinking and Dual Track Agile.

What is the Dual-Track Agile?

In a nutshell, the Dual-track agile is a type of agile development framework that combines a cross-functional product team and breaks daily work into two separate tracks: discovery and delivery.

The discovery track is suitable mainly for creatives and gives a validation of their unlimited ideas based on research and landscape analysis that eventually lead to creating a design system of some sort. Discovery track is a place where creatives roll out their sleeves and design the north star — a tangible prototype without the limitation of a technical environment can be put in front of the customer and tested against the criteria that the business, operation, management or marketing might have. This also defines whether the answer to the solution is really developing another piece of code or not. Under full transparency to the development team, designers tend to challenge our status quo and build the product not to please the ROI’s or KPI’s but to simply delight our customers and help them to become better human beings.

The delivery track, on the other hand, the delivery track allows the product owner to take these well defined and verified pieces of work (so-called increments) onto the production journey and with the advantage of saved time and resources on refactoring and extensive code testing. Without a doubt, a well-rounded development team will soon produce a working piece of software that represents the extension of an already validated idea in the previous track.

How does the dual-track work?

Please refer to these excellent articles from David Denham, who is describing Dual Track Agile from the business perspective for the development-led description Dylan Ward from the product perspective, who shares remarkable insights about the impact of dual-track agile on the development as they have done far better work on the development end than I’ll ever be able to.
Let’s look at the design perspective.

Step in

Before we can answer this question properly, we have to adjust a few things that are not part of the Agile methodology as per se but are heavily embedded in large organisations — mindset, dependencies, integration, ownership, ego-systems, and the so-called MVP.

The mind-set

One can argue that big organisations are hard to navigate and manipulate to achieve greater outcomes. Too many rituals, internal jargons, acronyms, groups, and teams have their way of doing things.

Yet underneath this is a mindset issue that’s often impossible to change.

By understanding the following, we aim not to change but to influence the right part of the business and unearth the opportunities lying behind these structures.

Product-led organisations historically tend to have strong development departments. Those usually start with the premise of resources and time, where the technology eventually dictates the rhythm and sometimes even the approach. This makes the delivery focus on the release — essentially what we can fit in this timeframe with this amount of people.

On the other hand, we have a design team — starting from an unknown problem without having an immediate solution. This inevitably creates tension between the team members and the business.

“How many times are designers asked to deliver the solution in one sprint without actually understanding the problem?”

Dependencies

That brings us to dependencies. Very few companies have done the full cycle from insights to Service Design, Prospecting, Prototyping, and seamlessly building under agile.

It always gets one team to discover — usually in the form of digested PPTX where the very next thing is buying an off-the-shelf platform that is rarely customisable. The second team does the design.

Then there’s the handover in a beautiful keynote presentation promising great value and customer satisfaction from beautifully shot pictures and giant size typography.

In fact, what has been needed was to understand the system-led dependencies and address non-technical operations. Or perhaps implement the simplified technical proposal that reflects the operational changes — 70% cheaper and 200% faster.

Building the feature in an environment that depends on integrating another feature or features might be a quite challenging task. Sadly business has its own way of dealing with dependencies. In companies with a more dominant CTO voice, the approach to the dependencies might be simple as using agile to generate an incredibly long backlog. This prevents the team from focusing and really delivering on the premise in any form of Agile.

Gathering the tasks in one place allows the smart team to go through the sequence of dedicated meetings to resolve and assign the priority and move most adequately forward.

Not every problem can be solved by agile, but this simple dual-track agile method has proved very effective when it comes to dealing with complex dependencies.

Integration

Equally, as the above example in today’s world, integration is closely tied with success. There are very few entities or solitude propositions that are not integrated with an API or another service — client database, marketing analytics, social platform integration.

The very first screen we often design is how to log in by using social media login. Most of the propositions these days are so unique that they will have a million customers from day one.

Dual-Track allows you to plan a play on the nuances of integrated services and get the most out of it by testing throughout the entire proposition.

That also helps designers to reuse and integrate different patterns, libraries and frameworks. After a short discussion with your development team, if carefully crafted, you can save the business 20% of the time to market and at least 30% of your time to create yet another design system.

Ownership

Dual-track helps both teams keep their routines and contribute to the same cause. I’ve explained once the ability to look into someone’s kitchen and see what they cook. You do not necessarily have a chance to influence it unless you are a product owner.

In the design kitchen, the design team plays with colours, transitions and animations where developers observe and influence. The dynamics are apparent (80/20) as the outcome of these sessions. Everyone is safe as these are visionary discussions.

On the other hand, once the prototype is moved onto the product line (by the product owner only), the dynamic changes; designers become supporting, and leadership moves on to the development team (20/80). This ownership redistribution ensures at first clarity about what we are looking at, dynamics about the scarcity of not being able to build it, and lastly, it allows all team members to have a very clear understanding of the stage they all are at.

Ego vs Eco-systems

Ryan and his book “Ego is the enemy” describes how the possessiveness of our own ego prevents us from achieving more significant outcomes.

It focuses us on concentrating on our own progress, understanding and development. Now more than ever, the contribution to a broader vision and helping to build the picture together is far more important than the perfect pitch or perfect UI screen or perfect piece of code.

Collaboration and participation from our little bedrooms are far more important than ad hoc detailed delivery.

Ego-Systems are situations that:

• Are hard to define where you are and what you should be doing
• Have a proposition created by one person driving the show
• Have no empirical research and insights
• Possess a design system or its parts owned by one designer in some team or function.
• Have a product owner designing the future product in PPTX
• Have a development team is not part of the definition, not even discovery.
• Never-ending chatter on Slack or MS teams without tangible agreement.

Examples of the Ecosystem;

• A transparent knowledge base builds by all participants in one place (team members — including insights, research, brand, experience and technology)
• Well-defined DoR, DoD and SLR, SLA’s
• centralised access to all tasks aka prioritised backlog
• KYC (know your customer) your research team is well integrated in the E2E process
• Experience has a clear strategy that is constantly tested
• Behavioural and navigational, including prototypes, are well known and easily accessible.
• The design system and all parts are governed and constantly updated to serve growing demands
• CX and UI are in the same place
• Ideally linked with assets management and UI Specs
• Development has access to all files and versions
• There is a testing URL or an APP I that everyone can see what is done
• Design > Develop > Test governance is a well-documented process.
• Balanced communication and documentation creation

The MVP challenge

In some companies, the Minimal Viable Product (MVP) is often considered as the final product, especially in organisations with the Ego-Systems. It’s understandable; it is defined, delivered on the date. Essentially it’s a tangible package. The Dual Track offers a more comprehensive and much safer avenue to release code as well as MVP itself. The main reasons are the transparency and well-integrated testing capabilities, which eventually leads to confidence and greater response to further challenges gained from continuous iterations.

Why is Dual-Track suitable for design teams?

Beyond the obvious about agile and its rounded philosophy about rapid, iterative, data-driven work, development inevitably leads to a better product. The dual-track agile helps designers to maintain almost an agency mindset. Thus, making small updates to their products, releases, and learnings allows designers to look into verticals that are often missed or overlooked at all.

Dual-track agile takes this philosophy of product development and iterative cycles to another level enabling other disciplines to contribute without the pressure of sprint delivery or pressure on handling the asset management.

These are my top 5 pillars I use to advocate Dual-track Agile for all product-based digital deliverables (helping across startups, agencies, SMB’s or corporate organisations):

1. Transparency

As mentioned above, TRANSPARENCY reduces ambiguity, hesitance, detachment and creates the opportunity for true collaboration. I’m not talking about a bunch of people huddling in their pyjamas over the Mural board where you can not even copy and paste. I’m describing a well-structured Atlassian workspace where all the live files are linked together, and each collaboration brings them closer to improve the current state. People do not repeat the same notes or resend the same email six times to make the team aware.

Transparency in Dual-track agile encourages teams to validate product ideas with the right focus and specific mindset. This means that product teams can increase the chances of succeeding internally in the business and externally with their customers.

2. Scalability

That brings us to scalability. Dual-track agile is the best choice for scaling, particularly when you scale design operations. You do not need to be a nerd or gig to see how the separation of tracks offers little waterfalls delivery points helping businesses to make the right operational calls.

Some propositions start with one UX-er and one UI Designer; when the project grows, you work with 27 designers of a different breed. At this point, not having a delivery method or changing one will simply generate inevitable frictions within the team, resulting in delays, costly changes, frustration, and loss of trust — without mentioning the fact that nothing has been delivered until this point.

3. Time to market

Reducing the time to market is the most significant selling point for the business. If you happen to be in the finance world, you’ll most likely deal with an MVP situation described above.

On the other hand, if you are in media, retail or any other more flexible market, you’ll certainly appreciate having flexibility and tolerance to release your best product on time.

Breaking the cross-functional team’s work into two parallel tracks — one devoted just to discovery and validation and the second to optimised focus delivery will allow you to release much faster but inevitably more often. And that’s the whole beauty of it: there is the mindset of constant improvement.

Faster to market means faster to find what works for the customer. This can result in faster development and release cycles and fewer wasted resources.

4. Lower Operational Costs

Finally, dual-track agile can lead to lower overall costs of product development for several reasons. First, the parallel-track nature of the discovery and delivery work can increase product development velocity. This means a cross-functional team can be making progress on both fronts simultaneously, rather than having one team somewhat idle while it waits for the other to complete their tasks.

It can also make validation itself more cost-effective. Under this system, items will not be allowed onto the product backlog until they’ve been validated by market research, usage data, or other objective means. This means the team will not waste time or budget pursuing projects that have not been validated or poorly thought out and will likely not help the product’s bottom line.

What all of this means is that dual-track agile can help an organisation focus on the right types of innovations for their markets and ship products users will actually pay for.

5. Overall Better Products

All the above describes how DualTrack Agile can elevate transparency, operate at scale, reduce the cost and time to market — more importantly, it makes it easier to build better and more resilient teams. Better products are built with better teams. The tribal leadership empowered team is often empowered by extreme ownership. This inevitably elevates all our colleagues from responsible employees to accountable, passionate contributors.

The product teams that are driven by leaders with neutral thinking and focus on bettering the team increase the chances of building the right product for the right audience (but on the topic of great teams make great products, perhaps next time)

Stay tuned; thanks for reading!
Thanks to all contributors especially Matt Press, for their insight and comments shaping this very article.
Jiri Mocicka is a London-based designer writing about his passion for the Design at Scale–integration and design operations that builds excellent digital products.