Dual Track Agile: the secret sauce to outcome-based development
The pivot towards outcomes
So you’ve created an inspiring Product Vision. You’ve moved towards a more outcome-based Product Roadmap, focused on problems to solve for your users. You’ve even started trying out OKRs, and using hypotheses to frame your more complex problems. This is awesome progress.
At the team level, Scrum/XP/Kanban are helping your teams deliver effectively. Your UX Designers and Product Manager are talking to users on a regular basis. However, when you talk to your teams, they still feel like they’re just churning out features— there to just execute.
When you talk to your designers, they’re saying their beautiful designs don’t look the same in production, and didn’t meet the specs.
What’s happening?
The importance of Product Discovery
It's without dispute that Product Discovery is an integral part of building products customers love. Design Thinking, Lean Startup, A/B testing and other methods have given us a toolkit to learn faster than ever what to build. Validating hypotheses without writing a single line of production-grade code helps us ensure we’re building the right thing.
When we talk about Lean and Agile, the assumption is we’re talking just about delivery velocity. That’s only half the story. We also need to think about learning velocity — how quickly can we discover?
Traditional Product Discovery happens as a phase — something that’s handed over to delivery teams after weeks or months of research. By contrast, to truly become focused on outcomes, we need to take a different approach.
The secret sauce — a whole team approach
Instead, we need to take a whole team approach, where Discovery and Delivery happen together in a parallel loop.
Here’s the secret sauce: with the same people involved in both, on the same cross-functional team.
1 team, 2 tracks — starting together, finishing together
This is where Dual Track Agile comes in. In a nutshell, this means developers being involved from ideation onwards. It also means designers need to be involved in delivery. And they’re on the same cross-functional product team, doing both discovery and delivery in parallel, in the same sprints or flow.
I first learned about Dual Track development many years ago from Jeff Patton, author of User Story Mapping. Jeff talked about the importance of how you think of the value developers bring:
You shouldn’t think of it as two processes — just two parts of one process. And, I think you’re doing developers and others on the team a disservice not to involve them in discovery work. — Jeff Patton
Another crucial thing to understand is what success looks like. By moving to an outcome focus, we’re shifting away from thinking of on-time scope delivery as success:
The whole team is responsible for product outcomes, not just on-time delivery — Jeff Patton
Maximising the value of your developers
It turns out developers are awesome problem solvers. Having them “shifting left” and being involved in the upstream discovery work, is not only great for ideation, but when it comes to delivery, it means they have the full context of the problem and solution, and can also make better technology choices.
Great, but how does it play out in real life?
Lead with the why, not the way. — John Cutler
Now that we’ve explored the why, here are some ways. However, please don’t fall in love with these. They are some patterns from some people way smarter than I (with my own take on them), which you may find effective in your context to try out a Dual Track Agile approach.
So, here are 3 actionable things you can try to get started:
Tip 1: Try Design Sprints - with your whole team
The Design Sprint, popularised by Jake Knapp when he worked in Google, is a great way to take a whole team approach to discovering a big user problem to solve, to empathise together, to ideate together, to prototype together and to hear from real users together. All in 5 days or less.
Tip 2: Get rid of your “Done” column
This sounds like sacrilege, but getting rid of your “Done” column on your program level Kanban board (that’s a post for another day) is one way to get the whole team thinking more in terms of outcomes rather than outputs. You see, we are only done once outcomes are met. How about calling it “Delivered” — and having an “Outcomes Validation” column afterwards? This means Delivery is not just for developers, its also for designers, and the Definition of Done extends to validated outcome.
John Cutler has blogged about visualisation patterns to nudge a system in this direction — I’d really recommend checking out his blogs.
Tip 3: Visualise UX activities in the whole flow on team level Kanban boards
This pattern also comes from John Cutler’s blog post — Where do we put the UX tasks? Design discovery and delivery work needs to be a first class citizen at the Cross-Functional Product Team level (note, I did not say Delivery Team).
Research work could be visualised upstream before your Ready or Up Next queue, with designers as your 4th Amigo in your backlog refinement. And then during In Progress, Design is also involved as a task in delivery and working closely with engineers sitting together whilst its being developed and tested. This approach also means that at your Daily Standups you’re discussing delivery, not just development.
This pivot needs deliberate practice
I have the fortune of being involved in the awesome Agile-Lean Ireland community to learn about some of these patterns and have experimented with many of the above ideas and failed at others. The truth is, cross-functional product development is a beautiful mess. It can feel counter-intuitive. A Dual Track Agile approach takes time and lots of practice to be effective.
However, with deliberate practice, the odds of achieving the desired outcomes that stemmed from your Product Roadmap significantly increase.
How does Product Discovery and Delivery work for you? Does it happen far upstream for development, or does it feel more integrated? I’d love to hear your approaches and any feedback on this post.