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…