Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Undertaking Design Work within a Dual or Multi-Track Development Process

Creating a shared understanding and ownership around what you are trying to learn, test and build is hugely motivating and empowering for both teams and individuals. If you are a collaborative designer who enjoys working with Agile principles and Lean UX methodologies in both discovery and delivery, Dual Track processes may work for you.

In principle, I love the concept of Dual Track. Done well, a Dual Track Development Process enables quick and efficient test and learn cycles, helping designers and their teams create better experiences in the product, systems and services they engineer together.

Additionally, Dual Track, as an enabler, has team and cultural benefits. These benefits may be optimised in the way opportunities are discovered, how problems are defined and which solutions are delivered to the user. Including the members or representatives of self-organising cross-functional delivery teams in the discovery process enables team engagement.

Also, a throughput of knowledge within the team, from understanding the business or customer problem through to how a solution is is tested and optimised in market, creates team superpowers and a better shared understanding.

Dual Track, done well, has team and cultural benefits in how well opportunities are discovered, problems defined and solutions are delivered to the user of a system, product or service

Note: This is the long form version of this article. Short form articles will be coming soon!

Before we go too far, what is Dual Track?

Desiree Sy came up with the term Dual Track in her research paper on Agile user-centered design for Autodesk (2007). Jeff Patton picked up on this and subsequently explained it as a development approach. In my mind, it is a process method that, if followed with discipline such as adherence to an Agile mindset and Lean approach, can be very successful in delivering value to customers and exciting to participate in for teams.

The great thing about Dual Track is that it essentially ‘kills’ the idea of innovation happening in isolation and gives the ability to innovate back to the delivery team populations too, rather than having a top-down, waterfall to delivery effect.

The great thing about Dual Track is that it essentially ‘kills’ the idea of innovation happening in isolation.

Dual Track development, with an Agile mindset, enables teams to run discovery to analyse and de-risk opportunities. This should happen first, before “feeding” delivery with ideas that have proven value for both the business and the customer, reducing waste as well ensuring technical feasibility. Opportunities that have successfully passed through the discovery process are either adopted into the release backlog or ‘killed’ before they reach development.

If passed through discovery successfully, this means that the opportunities that reach delivery, and therefore potentially accepted into to core products, systems or services, meet the minimum accepted value (MAV*)incorporating desirability, viability and feasibility, to de-risk delivery time and effort and optimise innovation.

The minimum accepted value (MAV*) considers the desirability, viability and feasibility of opportunities or ideas.

Three Innovation Drivers (Tim Brown, IDEO, 2006)

This approach is complementary to Agile approaches and associated methods such as Continuous Delivery, Continuous Improvement (Kaizen), Lean UX and Human or User-centred Design. The reason for this complementarity is that Dual Track processes enable teams to be set up to identify building the right thing, for the right context, at the right time, with the right people.

Jeff Patton’s illustration (below) describes ‘Learning Velocity’ and ‘Development Velocity’. As you can see from Jeff’s diagram, some things go in to the release backlog and some things don’t.

Illustration from Jeff Patton’s article “Dual Track Development is not Duel Track” (2017)

Dual Track development is a product, design and engineering process. Within software development, design, product and technology work together to engineer a product, system or service. Therefore Dual Track is a process methodology that we can apply to anything we design, build and test with customers.

Dual Track development is a product, design and engineering process.

Test and learn cycles can be applied in both discovery and delivery. Rapid feedback loops are incredibly important in enabling opportunity creation, speed to market, value assessment, use-case assessment and understanding customer expectations quickly. The value of learning for a team can be applied to any cohort of people that are affected by the opportunity you are discovering or delivering to market.

Given the learning benefits for teams, Dual Track sounds very human-centred doesn’t it? And this benefit doesn’t only apply to users and customers, but our teams too. Designers are curious, as are our colleagues, therefore it is difficult to resist the attraction of a Dual Track delivery process done well, with an Agile and Kaizen approach.

Why did we choose Dual Track development?

To provide context, we were a new team and spinning up adjacent to the core delivery teams around known entities within a large organisation with millions of users. Established delivery teams were focusing on defined and known customer groups, while we were considering a new customer and problem domain. Given my team had some freedom around how we could choose to deliver, we considered what we needed to do and that naturally pointed to something like Dual Track development.

Our decision was an outcome of a huddle between the team leads, describing what we needed to accomplish when someone said, “that sounds like Dual Track.” So Dual Track, in our context, resonated with us. We were thinking about how to enable speed to market and learning. We identified possible growing opportunities emerging as a result of a single Vision track and multiple stakeholder engagement exercises as well as a preliminary learning phase including lean research and customer interviews.

The Vision track then kicked off a secondary track, Experiments, fed by the Vision track. These functioned synchronously. Once the Vision track has a defined ‘customer journey’ and opportunity or ideas backlog associated with it, it will then naturally evolve into the Discovery track or potentially persist as the customer journey is iterated on. Streams of initiatives might flow out of this evolved Discovery track, triggered by the customer journey target state and the opportunity and ideas backlog.

It’s important to remember, based on your learning stage in research and discovery as well as data confidence, that whether Single, Dual or Multi-Track, you can spin tracks up and down as needed, just like discovery and delivery streams. These tracks may be dedicated to different approaches such as vision creation, experiments, discovery or delivery teams. These tracks and streams can be activated and de-activated based on your program maturity stage too. To picture this in your mind, see tracks as vertical and streams as horizontal, like the picture (above).

Our team scenario with Dual Track, in a little more depth

We chose to run a Dual Track process model with an Agile approach because we needed to run discovery and delivery quickly, on a critical business strategic path, with what was initially a single, small team. We were right at the beginning of the learning journey and wanted to test and continuously learn in a Lean and efficient way, with what really became a Kaizen mindset.

We wished to mitigate risk and both architectural and experience legacy by avoiding building changes into our core systems, before we understood the customer and business value of what we were seeking to change or innovate around, to the best of our ability and if, in fact, we could build and test the ‘thing’ at all. As a team, it was our desire to learn from a small cohort of engaged customers before we scaled any solution to a significant percentage of market exposure. Therefore because of our need for efficiency, we required near-state, attainable outcomes to kick the team off and incept experiments. We proceeded to production code quickly in order to evaluate concepts that were considered within reach and we had reasonable high confidence about, to test with the target market.

Finally, if we could understand the parameters of the value we sought to deliver, with what might potentially create a new product adjacency to our core market offering as a business, potentially a new roadmap of prioritised opportunities and learnings could be pushed to market in the short term while we learned about longer term opportunities for our business with this hard-to-crack customer segment.

The Dual Track process model isn’t really the solution, rather the impetus to move forward as an enabler. It’s how the team and individuals interact with the way they are organised and what protocols they have in place to understand why they make decisions that matters.

So as you can see, the Dual Track process model isn’t really the solution, rather the impetus to move forward as an enabler. It’s how the team and individuals interact with the way they are organised and what protocols they have in place to make decisions. You could easily argue this isn’t Dual Track at all, however it helped us get to where we are now.

How does Dual Track impact on the way a team interacts with each other?

Dual Track development, underpinned by the twelve Agile Principles, can impact on team behaviour in a range of ways. When done right, these are positive.

For designers, relationships are crucial, particularly in a UX and Product roles. Communication within the team and without are business requirements of our respective functions, albeit with a user experience or business focus.

Here is a top level list that just touches the surface of benefits of Dual Track development, if it’s done right:

a) Dual Track development forces collaboration and co-creation with your team and allows for customer and user-centred activities;

b) Dual Track enables the team to be involved in both discovery and delivery, which is motivating and empowering for the team;

c) Things move quickly! Designers and their team-mates must be learn to be nimble, which is a good thing (I’m biased) and instils a learning mind;

d) Dual Track works best with Agile, human-centred rituals that maintain strong communication behaviours, encouraging honesty and alignment. Being in sync with your team is important as is trust, anchoring to your goals and aligning with each other; and

e) Most of all Dual Track development is exciting and fun, once the team is comfortable with change and making decisions at a pace. For us it was running experiments, but later it could be adding features into the core system, products and services.

Dual Track is complementary to Continuous Delivery in that they keep the wheels of the team moving with new initiatives that may be retained or discarded

It is worth noting that the benefits of Dual Track might also apply to other Agile development processes such as Continuous Delivery. Dual Track is complementary to Continuous Delivery in that helps both spin up opportunities for delivery to test and learn, as well as keeping the wheels in discovery moving with new initiatives that may be accepted into delivery or discarded as low value.

Issues for designers re: speed and ‘loss of craft’

Designers may sometimes seem resist the ability to work quickly in lower fidelity because they may rear the risk ‘loss of craft’ in the interface. However, this is not a team but systemic design issue.

For example, if design pattern systems are not in place, increased fidelity designs might be required to maintain a standard consistency across the delivery of user-facing system improvements, or the identification of new opportunities for pattern and style guide creation.

Designers may sometimes seem resist the ability to work quickly in lower fidelity because they may rear the risk ‘loss of craft’ in the interface. However, this is not a team but systemic design issue.

There are many ways to identify ‘loss of craft’ and designers simply need to be flexible and communicate this to their team members. Not unlike the impacts on technology architecture, designers must consider this conversation an extension of the ‘system architecture’ legacy.

The importance of psychological safety in fast moving teams

Psychological safety is hugely important to create an anchor for alignment and resolving in-team differences and moving the team on to progress to the next task or objective. To be successful in Dual Track Agile, or indeed in any other fast-paced delivery approach, teams must create a ‘safe’ environment for collaboration and autonomous decision making, guided by shared team goals and success criteria for sprints or epics.

Trust and honesty in communication, when safe and respectful, can help mitigate everyone’s concerns around decision making and how to eliminate workflow issues. The importance of regular retros and actions coming from these rituals help support a psychological safety agenda.

Common issues for designers in fast moving teams might include:

a) Designers might feel ‘out of sync’ with their counterparts, especially if there is one designer doing ‘all the things’ (see: unicorn). This issue can be counteracted via simple communication and adjusting the team engine’s gears to accomodate the right workflow in product, design and engineering to assist the designer;

b) Designers might have different perceptions of the value of fast-paced discovery and delivery cadences and need help adapting to the team, similar to a) but around the ability to learn and adapt;

c) Designers may have distinct and varied expectations around what their role is responsible for, or their ownership of key deliverables such as interface design vs an engineer making in making interface decisions. Designers and their colleagues must learn to respectfully ‘share hats’ in order to keep progressing quickly and retain a positive team culture;

d) Team-colleagues of designers may also have different ideas on what they expect from the designer and again, simple communication around “what I expect to do” vs “what you expect I do,” helps between both parties; and

e) If inexperienced in Agile or early career, designers may find it difficult to adapt initially to Agile mindsets and Kaizen workflows and need support around losing a perfection mindset to shift towards test and learn. This may also be a team expectation reset so all are aligned and can move forward.

Shared objectives and key results or success criteria

In our case, the team used the Google OKR Framework and created OKRs to align against. We designed the OKRs together and, resultingly, the objectives and key results gave us an anchor. There are many advantages to having a shared goal or objective and this is a key alignment factor for both the team and the organisation and/or users you are serving.

For example, there is an in-team or stakeholder dispute about an idea, design, or approach, OKRs might help to re-orientate the conversation and align the team to make effective decisions without hamstringing discussions with opinions that may derail team goals and objectives. You might also apply this technique to acceptance criteria on a card or success criteria for a sprint.

OKRs can help align the team to make effective decisions without hamstringing discussions with opinions that may derail team goals and objectives.

Pro-tip: You might also apply this technique to acceptance criteria on a card or success criteria for a sprint.

Dual Track, given its time contingent nature, may pose issues if a person is down or out of the office eg. you are sick or on leave. Often, if there is only one designer per team, or one anyone, the absence of a key function can be hair raising! For example, if the team don’t have an understanding on how to operate when a key team member is out.

In a healthy, well functioning team, aligned to their objectives and key results, it should be ok and safe for the team to make a decision around whether or not to move forward without a key team member representing their function, knowing that there is a shared understanding underpinning anything the team decides to do. The team can always circle back later if needed, but a key thing with Kaizen is waste reduction, so keep that in mind.

If a team member is out of sync with your team, in fast moving situations like Dual Track or rapid delivery timeframes, one may need to accept that design decisions might be made without them if they are not there. This might also apply to designers. Therefore, keep the oil in your team mechanics; make sure you lubricate your communication skills by attempting to be as available as possible for your team, attending team rituals in person, or remotely, and most of all killing your darlings through cross-functional and customer-centred collaboration.

Kill your darlings through cross-functional and customer-centred collaboration.

Obviously, there are cases where decisions without designers aren’t optimal. If a designer is really needed to make a call, it is up to the team to be able to shift gears in a different direction, speed up/slow down, without holding up progress or moving cards across a wall. This may also apply to spinning up a new team in the discovery track, for example, if a key team member representing product, technology or design is not available, wheels should pause until the functions are represented.

As a designer, if you establish a shared understanding with your team on objectives, this will underpin trust, confidence and alignment.

Agile team rituals such as regular retros will help your team identify bottlenecks and problems then activate actions from your learnings and team decisions that result in actionable results and improvements in the way you work together.

If done wrong, the effects of Dual Track are potentially damaging to teams, creating the ‘Duel Track’ effect;

a) Discovery teams working in isolation;

b) Opportunities being handed over in a waterfall handover process;

c) Team engagement in delivery affected by a lack of a shared understanding around the problem being solved and lowered efficiency as a result;

d) Discovery being misunderstood as a solution creation process… it isn’t, discovery is a problem definition and opportunity assessment approach; and

e) Worst of all, team members might resent each other and throw tomatoes emoji over the walls (joke) and culture is affected.

Our team, so far has had huge success with an awesome Agile coach who has been managing the retention of team rituals and communication. If you’d like to read more about psychological safety, this is a great article from HBR. It’s hugely important to a learning mindset.

Sometimes all that is needed is a “hey, we are doing this thing right now and this is why” kind of conversation. This is where trust is the team’s bedrock, especially if teams can’t afford the time to include everyone in delivery in discovery conversations and vice versa. Walls are great too, so team members and stakeholders can read things, as is having shared stand-ups and time together in show-cases so everyone feels included in the ideation and execution process. For designers, this is hugely important.

So, it’s really important to think about what smoke signals to look for, in order to avoid the negative effects of exclusion and isolated behaviour and build the fires of passion in your team.

In conclusion, what’s in it for designers?

The learning mindset is so valuable in team motivation and understanding stakeholders as well as the needs of users of products, systems and services. Given Agile experience design is very similar to and can be adapted towards a kaizen process, it’s really important to embrace enablers that might help your team work more efficiently and collaboratively. Within reason, any framework or process that supports engage with the people your system interacts with is worth an experiment and if working well adopting into your day to day processes as a team.

It’s absolutely worth experimenting with Dual Track development and researching best practices around Agile and Growth Mindsets, so you and your team can explore the value of collaboration and see if it improves your ability to receive timely information on how to design and build the best experiences for the users of your product, system or service.

* If you’d like to know more about the idea of Minimum Accepted Value (MAV) please contact me direct. I created the acronym and concept after a long time of thinking about the connect between human-centred design and IDEO’s value drivers with continuous delivery. I put two and two together when I was thinking about this article. It’s an ever evolving conversation