Dual-Track Agile: Better Products Faster
Originally posted on The PM Vision (now defunct). This version has been edited for clarity.
The Perils of Short-Term Vision
Product managers have access to limited development capacity but infinite requests for features.
It’s important to solve the most important problems first; once priority is established, it becomes critical to understand the problem and then deliver a solution.
Too many teams struggle to build effective solutions once the next “most important” item is chosen. They solve the wrong problem. They address the correct problem with an ineffective solution. The solution requires rework once the next need is considered.
Dual-track Agile is a way to solve those problems.
Which of the following problems have you encountered?
Agile product teams don’t think beyond the next couple of features.
Agile development teams think one feature at a time, and do extensive rework when a subsequent feature changes the implications of the previous.
Solutions aren’t vetted with customers or stakeholders until after code is written, presumably using the “minimal marketable” version of a given feature.
When a team is ready to work on something new, engineers have to spend precious time defining and understanding the need.
Alternately, if a solution is proposed, engineers begin to analyze the poorly thought through idea that is brought to them to build, and waste cycles getting answers and devising a better solution.
Subsequently, there are sales and prospect expectations to reset.
Once the capability is released, other needs that stack upon the first result in rethink and rework. This is the dreaded refactoring that people frequently consider to be engineering’s way of wasting of time, but which is often the result of building things without thinking them through first.
That said, because the teams haven’t planned very far in advance, at least there aren’t long term plans to rework when Sales kicks over several new features that “we have to include in the contract” to win a deal in the intermediate term.
There is a better way.. but it requires a shift in thinking in both product and client negotiations.
What is Dual-Track Agile?
Via Marty Cagan, I became acquainted with Jeff Patton’s concept of “Dual-Track Scrum.” I use the term “Agile” to be more inclusive of other agile methodologies like kanban, scrumban, etc.
Dual-track is an organizational structure separating the effort to deliver working software from the effort to understand user needs and discover the best solution.
It is only by iterating through a number of options that the best solution can be identified and “discovered.”
Refactoring is natural when you’re pivoting; when you’re making earth-shaking discoveries about your market and their needs.
However, if you’re building product for a known market, offering a product with a fairly well understood shape, and still experiencing frequent refactoring, you probably aren’t putting enough effort into product discovery.
How does this work in practice?
Each track is given a general mandate: discover new needs, or deliver working software.
Taking the baton first, the Discovery track is responsible for validating hypotheses about solving user problems, and preparing user stories for the Delivery track. This means the Discovery track is learning about users in depth, analyzing feature requests, and drilling down on high priority needs.
Here’s how we executed this at The Network [now part of NAVEX Global]:
Step 1: is that the Product Manager provides a prioritized list of user needs & feature requests and helps to explain the need for each.
Step 2: the Discovery track generates an understanding of requirements, wireframes and — using a series of Design ‘N Architecture (DNA) meetings to answer technical questions — architectural approach. This is executed by a three-part team: the Product Owner, the User Experience lead, and an architect from Development–similar to the Product Owner Team that some companies employ more formally. (The Product Manager is involved for us at this point, generally for the purpose of elaborating on the need and providing feedback concepts generated by the Discovery track.)
Step 3: the Delivery track is responsible for delivering working software each iteration. They take the artifacts generated in the Discovery track and creating the detailed user stories required to deliver on those ideas with acceptance criteria; and for delivering the working software. The Product Owner guides this through the process with little involvement from the Product Manager except for checkins. This gives the Product Manager time to interface with clients and client-facing teams.
Early lesson learned: ensure someone from the delivery team is involved during discovery, or you may create an unintended waterfall handoff that isn’t pleasant.
What is Discovery, exactly?
Discovery is a form of purposeful iteration on solution options. Designers create solution approaches from the needs brought to the team by Product Management.
The Product Owner, Business Analyst and User Experience representatives whiteboard wireframes and talk through happy path and edge cases to see if a design holds water. When it doesn’t, changes are made and the cycle repeats.
Simple features may require only a few iterations; more complex ones may be iterated on for several weeks off and on, woven in with other responsibilities.
But it sure beats releasing software only to find that something wasn’t considered.
When the team is confident in the design, it’s put in front of others. Members of client facing teams are invited to a walk-through, and advisory board clients are recruited to provide feedback.
For critically important features, everyone’s feedback is considered and the design meets all known concerns.
Compared to a process where features were built using the first design that came to mind and little critical review, this greatly improved the confidence in deliverables from the rest of the business and drove better outcomes in a short time.
What’s the time horizon of Discovery?
In our organization, we struggled with understanding the time horizon of Discovery. There are two sides to this discussion.
For existing products in market that are feature-poor compared to competitors, especially in a mature market, you may have a fairly clear understanding of what the product will look like in the future. In these cases, it’s sensible to do a Story Mapping exercise to paint a picture of all the key functionality, so that you can craft a sensible plan for how to get there in the most advantageous way.
During a catch up exercise, mapping out which needed features will have the biggest impact can buy you time to build more nuanced features, and in some cases eliminate or greatly reduce the need for others.
At this stage you can think about things like taxonomy, mental model, and other core concepts that allow you to organize and structure the application optimally. You can also think about how big components will fit together, and break up capabilities in a corresponding fashion, to expedite development and to ensure future features have a place to fit in the application structure with little to no retrofitting.
Discovery focuses on those high-ROI items in order to get them built out first. This is how you “catch up” when there are a lot of gaps.
At the same time, client requests may be coming in. You’ve got existing clients with pain points, and prospects demanding certain gaps be closed contractually. Therefore, to meet business needs, the Product Manager likely has high priority needs mapped out on the roadmap, and is pushing to have Discovery around those items conducted first.
Ideally, if you’ve done enough Long term discovery, you have considered how some of the short term needs will be met, and you have an idea of where in the framework they would be built.
Depending on timeline, in order to meet contractual requirements, you may need to work on some features prior than is ideal. Here you’re hoping to do enough discovery and to be able to construct them with as little risk to the core direction as possible.
The risk in this approach is you build features that don’t account for the fundamental pieces you know you need, and find yourself performing refactoring when it’s time to build them in a more sustainable fashion. This requires balance.
Product owners are responsible for release targets, so they’re thinking in terms of specific functionality to be delivered within a given timeframe.
This process has encouraged another opposing point of view: Imagine what the world will look like with the problem completely solved, and then schedule which parts of that solution to build in the time available.
It requires some mental gymnastics, but implementing such a process can result in noticeable payoff.
We found that while navigating the chaos of current client needs, this process encouraged us to find opportunities to address multiple needs with a single effort. Bigger ROI for the same time investment.
Buy-in can be a challenge.
Skeptical coworkers may not be convinced until they see the impact of features that have gone through a robust dual-track process and until you clearly illustrate the tangible impact of decisions you make now on needs that weren’t expected to be addressed quite so quickly.
How does Discovery affect Product Outcomes?
Discovery minimizes refactoring.
As we discovered, spending enough time on discovery prior to building software helped ensure we thought things through properly.
Sometimes it feels excruciating.
You have gone over this already. But now someone wants to look at it from what feels like a 37th perspective. So you walk through it again.
And you notice something.
So you make a tweak to your design.
Unbeknownst to you, that tweak saved you a week of refactoring–or even an emergency patch–that you would’ve had to perform had that design flaw made it into production.
If you’re solving a brand new market problem that no-one has solved yet, you may not be able to think about things from 37 different points of view.
But if you’re going into a crowded space, or solving additional problems for a market you know extremely well, you are doing yourself a disservice if you don’t think things through early on.
Even if you’re agile, when you’re building feature upon feature, flaws included in the core functionality become expensive when you discover them later.
And “we didn’t think of that” is still a flaw even if you weren’t “supposed to.”
Those weeks of refactoring are a direct drag on speed.
Discovery increases developer confidence.
Another impact of Discovery that I’ve personally observed is an increase in engineering confidence.
Developers, as a group, ask a lot of questions.
Developing a system from nothing requires a deep level of analysis most ordinary people can’t fathom.
This puts a good deal of pressure on a mere mortal product owner.
One of the product owner’s primary tasks is to be available to answer development team questions.
Many of those questions are simple. “What label should this button have on it?” “Why would someone fill out this form?”
“What should happen when someone tries to submit this form but leaves the SSN empty?” “What happens if the patient’s status is discharged when the form is submitted?”
Developers love to explore edge cases.
And their confidence decreases the more times the product owner has to say “I don’t know” and speak with stakeholders.
Confidence grows when the product owner knows what she wants, and is able to communicate it concisely.
That knowledge comes from having thought things through beforehand.
The discovery process is where that detailed analysis takes place.
Isn’t this just Waterfall?
One of the primary concerns I had when I first encountered the approach was that with so much pre-work, I sensed the smell of waterfall.
But that was only an early concern.
We were still able to shift as new information was learned. In fact, Dual-track encouraged us to learn new information.
Business priorities still took the lead.
The reason it smelled like waterfall, in my opinion, is that we were too agile. Because we assumed we didn’t know what was coming next, we resisted doing too much thinking ahead.
But in scenarios where a product offering has clear gaps against competitors in a defined market, that wasn’t true. We do know what we need.
We might not know what’s coming next.
But even that wasn’t true.
Given that we know where the product needs to be, we have a pretty good idea at a high level of what to build in what order to satisfy future needs.
We don’t know what the next prospect will ask for.
We had to learn to communicate why staying on the current path is–in some cases–better than chasing the shiny object.
But we still required the freedom to chase the object when appropriate.
Dual-Track didn’t stop our business agility. But it did make us think twice about changing directions, which in our case I believe was healthy.
How does Dual-Track Agile benefit Product Managers?
It should be clear from the above points that outcomes driven through dual-track are often better solutions to customer pain points than without such a process, and tend to require less rework.
I observed in one anecdote about implementing dual-track Scrum that the Product team drove the change:
I think it’s important to note that the driver for wanting to adopt Dual-Track Scrum came from the product team. This is the way they wanted to work, and I and the other delivery managers helped the product team bring this change into the company.
This isn’t a “development” change. It’s a driver of business value.
Much as I’ve suggested that the business needs Product Management to be Agile, product management is the beneficiary of better solution discovery, so they should be pushing for it–whether it’s Dual Track or something else.
In dual-track agile, the same investment of time is more impactful linearly and indirectly.
I’m hoping to see in my current environment over time that having Discovery finished when a feature is ready to be built consistently drives faster Delivery. So far I’ve seen that in one instance but I cannot claim a trend.
Who wouldn’t want better solutions faster, with less rework?
