Dual Track Agile: Focusing on Customer Value
When managing software products and agile development teams that create them, two common problems nearly always seem to emerge:
- The development team feels like they get involved too late in the planning process.
- The team is frustrated by incomplete stories entering sprint planning.
The funny thing about these two problems is that the development team might seem to be contradicting itself, asking to both be involved earlier and not to be involved until the planning is complete.
What’s the solution to this seeming contradiction?
The Dual Track Agile process
Dual Track Agile is a way of organizing and planning the work of an agile development team that solves the problems I pointed out above — and several others for good measure!
Let’s start from some first principles and build up the Dual Track Agile process iteratively, in true agile style…
Step 1: The feedback loop
Why do we build software at all? Unless you are at home building something for personal enjoyment, hopefully the answer is to solve the problems of some customer.
Assuming this is the case, let’s start with the team of people building that software. We’ll call them the delivery team, and it is their job to deliver a solution to the customer which solves their problem. The delivery team consists of developers, a technical leader — who we’ll call the tech lead — and someone to ensure the process goes smoothly — we’ll call that person the scrum master.
Each increment of value that the delivery team delivers to the customer is usually realized as a new software feature or a modification to an existing one.
Once the customer uses the software and tries to solve their problem with it, they respond to the delivery team with feedback in the form of ideas: bug reports and feature requests. Those ideas are then processed by the delivery team, who creates a new increment of value (some software change) in response to them.
This feedback loop is at the core of delivering software which customers will use. And the faster we can deliver value to the customer, the faster we get their feedback, making the value of the software to the customer higher.
Step 2: Reality meets the feedback loop
Our simple feedback loop as described in Step 1 captures why it is important to get fast feedback, but unfortunately, the realities of building software and serving customers makes the picture a little more complicated.
First, some ideas are impossible to implement (in other words, they are not feasible), so the delivery team throws away the idea, and it never gets released to the customer.
Second, it’s inevitable that there will always be more ideas coming in than the delivery team has time to implement, so the ideas will build up over time and become a backlog.
Over time, this backlog will of course get longer and longer, until the delivery team is completely overwhelmed and unable to respond to the customers quickly.
How do we deal with this ever-growing backlog? The solution is the product owner.
Step 3: The role of the product owner
In order to get that backlog under control, we add the role of the product owner. The product owner is not a member of the delivery team, as she is not building the actual solution. Instead, she forms a separate “team” that functions in unison with the delivery team. Together, the delivery team and the product owner form a single super-team responsible for bringing value to the customers.
The product owner is responsible for looking at each incoming idea and ask the question, “Is this valuable?”
If the answer “no”, the idea gets thrown away.
If the answer is “yes”, the product owner takes the idea and creates a user story — a clear statement of the problem that needs to be solved — and prioritizes it in a product backlog. Whenever the delivery team is ready for more work, they can take the top priority story off the product backlog and work on turning it into value.
Step 4: Handling ideas better
The biggest problem with our model so far is that it assumes we create software in a purely reactionary way. If all we did was implement what the customers told us, we would end up with bloated software that does hundreds of different things — and none of them well.
We need to ensure that we are working toward a greater purpose for what the product should be. This purpose is described by the product’s vision and goals.
The vision and goals become sources of ideas on their own, but they also help us judge ideas coming from customers. If a customer’s idea doesn’t fit our vision and goals, we can throw it away.
With all these ideas coming in, the product owner needs a place to keep them. These ideas are organized into an idea backlog, sometimes also called an opportunities backlog.
Step 5: The role of the tech lead
If we were to stop at Step 4, we would have a pretty good description of how agile teams traditionally work in a Scrum or Kanban environment. But with Dual Track Agile, we go much further.
If we take one developer from the delivery team, the tech lead, and have her work more closely with the product owner, she can help the product owner identify and throw away ideas that are not feasible.
So we have the tech lead join the product owner in the discovery team. Now, with the product owner identifying which ideas are valuable, and the tech lead identifying which ideas are feasible, we can ensure that by the time the delivery team takes a story off the product backlog, they can be sure it is both possible and valuable to turn into a software increment.
Life is definitely improved for the delivery team with this change, but what about the customer?
Step 6: How can we get feedback faster?
As I pointed out at the very beginning, the most important aspect of the whole process is getting feedback faster.
In the feedback loop like the one we have discussed so far, the speed of the feedback is only as fast as the slowest part of the loop, so in order to get the fastest feedback, we need to identify which part takes the longest.
What is the slowest part of the loop?
Almost certainly, building the actual software is slower than every other part of the process.
Can we speed up that part of the process? Obviously, we can’t get feedback on our software from a customer until we actually show that software to the customer, right?
“building the actual software is slower than every other part of the process”
But what if we could get feedback from the customer before we ever write a single line of code? (See the big yellow question mark, above.) Thankfully, there is a way to do just that!
Step 7: Faster feedback through prototyping
Instead of waiting until we have written software before we get feedback from our customers, we can show them prototypes. In terms of our diagram, instead of delivering the customers actual value, we can show them stand-ins of value, and then they can give us feedback on those prototypes.
So now the job of the discovery team is to create prototypes of the value we might provide to the customers. Depending on our product, the prototypes could be web page wireframes, API specs, hand-written document prototypes, or whatever else can act as a stand-in for the real product.
The product owner also gets an additional job of showing these prototypes to customers and finding the answer to the question, “If we were to build this, would (and could) the customer use it?”
Often, a product designer joins the discovery team to assist in creating the prototypes. His job is to ensure the prototypes are usable.
If the feedback from the prototype shows that the idea is valuable and usable, we can attach the prototype to the user story and add it to the product backlog, giving the delivery team even more guidance in how to build it. If the feedback shows the idea is not valuable, the idea is thrown away.
Step 8: The two cycles
Now we can see that we have two feedback cycles, not just one.
The discovery cycle validates the value and feasibility of an idea, creating prototypes along the way.
The delivery cycle delivers the value of an already validated idea.
While I describe two distinct teams here, the delivery team and the discovery team, in reality these two teams should work together to form one cohesive group, and they should succeed or fail as a group. And like all teams that work closely together, they are most effective when they sit together in the same space whenever possible.
The discovery cycle can be much shorter than the delivery cycle, since prototypes are easier to create than fully working software, ensuring that we get feedback from our customers as fast as possible.
The complete Dual Track Agile process
Now that we’ve seen every part of the Dual Track Agile process, here is the complete workflow:
Implementing Dual Track Agile in your business
I’ve implemented the dual track process in several teams and assisted others implement it in their teams, and while it is not always easy at first, I’ve found that after the initial acclimation period has passed, it is liked by both developers and product owners as a way to streamline their processes.
If you want to start using Dual Track Agile in your product development teams, here are a few tips that might help:
- Start by gathering together all the ideas floating around the product and create an idea backlog.
- After that, get the tech lead involved in evaluating the stories with the product owner before they end up in front of the whole delivery team.
- Next, start creating prototypes for the most obvious cases.
- Once the team is used to the idea and process, find ways to make a prototype for every significant increment of value.
Good luck!
Acknowledgments
My visualization technique was heavily influenced by the presentation Agile Product Management in a Nutshell by Henrik Kniberg.
The idea of thinking of the agile development cycle as two interleaved cycles comes courtesy of Marty Cagan, who I believe coined the term “Dual Track Scrum.” Note that I’ve called it “Dual Track Agile” here, because whether the delivery team is using Scrum or Kanban, the “dual track” part remains essentially unchanged. I highly recommend Marty’s book Inspired to anyone involved in building or planning software.
Thanks go to Josh Mauk and Jan Tryggvason for their help in reviewing this essay.
