In our previous post, Leveling up with Dual Track Agile, we gave a very broad sketch of the framework and why it’s useful. In theory, it makes sense, but what does it look like in practice to bring designers together with IT in discovery and delivery?
The questions we at Hard Yards often field include:
When is it appropriate to use Dual Track?
How do we implement it?
Who focuses on Discovery? Delivery?
How do you know when to do each?
How do you know when to stop?
This post is an attempt to unpack some of these common questions, and an invitation to continue the conversation.
What scenarios are best for Dual Track Agile?
We recommend you consider using dual track agile when your team:
A. Has inherited a legacy backlog that seems suspiciously devoid of value
B. Has been tasked with a new feature launch
C. Exhibits signs of “delivery tunnel vision”
D. Is already a performing team
E. All of the above and more
Our opinion is that the answer is E: All of the above and more.
For those that believe dual track agile is an “advanced” concept, our response is that it sounds far more complicated than it is in reality. It is nothing more than a means of continuous learning.
When is it important to learn? Pretty much always.
How do we implement the discovery track?
Typically, with Dual Track Agile, there aren’t separate discovery and delivery teams; rather, both functions are performed within each team.
The reason is that using separate teams creates unnecessary complexity in the form of hand-offs and dependencies, leading to delays and/or work getting lost in translation.
That said, there are exceptions. Some organizations will employ separate discovery teams for long-range exploratory research, like DARPA (Defense Advanced Research Projects Agency), or pharmaceutical companies.
They are doing discovery for Horizon 2 & 3 initiatives in order to position themselves for what’s conceivable down the road; not now or the near future (for what we don’t even know we don’t know).
Who actually does the discovery?
The UX/CX researcher/designer may lead the effort, but ideally, all participate.
Why? Because each perspective will consider discovery differently. The designer, the engineer and the business analyst will naturally listen for different clues and ask different questions.
This is often where we see philosophies diverge, so it’s worth going into greater depth using a relatable metaphor--home design. Consider the exterior and interior drawing of the Cliff Haus below:
Cliff Haus exterior
Cliff Haus interior
Ask a designer what they see. Now ask an engineer. Next, a business analyst.
A designer will instinctively look at the blueprint with the following questions in mind: Is the structure designed for the way the inhabitants live? Is it scalable, meaning, it is adjustable for when the family grows and ages? Does the structure encourage healthy living--is there an optimal balance of work/fun attributes, is it functional for operations, getting and receiving groceries, washing clothing, cleaning, cooking...and also rejuvenation and familial connection?
An engineer may look at technical aspects--the placement and tech around the guts of the structure--how it receives and delivers energy, heat and cold air, hot and cold water, sewer, wifi signals; how it is positioned in the surrounding environment to maximize efficiency.
A business analyst may consider elements like materials and cost. Is it scalable as a pre-fabricated structure? Is there a reasonable opportunity for profit? What are the tradeoffs if lower/higher quality materials are used? Is it eco-friendly? Who is the target market? Is it built for the way we live now or is it future-centric? What trends are going on in society that this particular style of housing speaks to?
Each of the three roles will provide different insights, hearing unique points of emphasis and asking pointed follow up questions, based on their area of expertise. And ALL should be looking at what other designs are out there to learn from i.e., secondary research. Who is preeminent in this type of structural design? What can we learn from them? What experiments have already been attempted, failed or succeeded? What feedback has already been collected from other builders, inhabitants, engineers?
Nothing replaces having these three perspectives performing discovery in real time together. It typically equates to saving not only time and money down the road, but also fewer quality defects. Conversely, if you cut corners here, it can mean the opposite.
Either way, you get to your perfect design to implement/build. And then something unforeseen like COVID-19 hits and suddenly, we are all living in a drastically different world.
Continuous learning is imperative because of this truism: The only constant is CHANGE. Nothing stays the same. Time never stands still.
So when do you start discovery? How do you know when to stop?
Don’t overthink it. Start now and never stop learning.
In the example above, the questions that arise as you mock up a blueprint are fairly obvious. But what does learning look like during delivery? Those could be observations that lead to adjustments on the fly. For anyone who has built a house before, this would be the changes made during construction, as 2D morphs into 3D and space becomes real. Later, the team continues to learn through data compiled shortly after move in, 6 months to a year afterwards and even as the inhabitants move through major life stages or environmental events.
All of that is to say that Dual Track Agile doesn’t need to be overwhelming.
Make learning a goal for each Sprint. Start somewhere.
We welcome your thoughts. Continue the discussion at info@hardyards.com or sign up for our ICAgile-certified Design Thinking for Product Owners virtual course.