tl;dr:

If you’ve heard the term “dual-track development” before, this article explains where it comes from, and what it means. Here are the key points:

• Development work focuses on predictability and quality
• Discovery work focuses on fast learning and validation
• Discovery and development are visualized in two tracks because it’s two kinds of work, and two kinds of thinking
• Discovery is a necessary part of product development. Practice it with the same agile and lean principles in mind.
• If we’re doing discovery right, we substantially change and kill lots of ideas.
• While a product manager, designer, and senior engineer may lead and orchestrate discovery, they must involve the whole team in discovery tasks wherever possible. Keep discovery work and progress visible to the whole team.
• Keep measuring and learning even after you ship.

Now, if anyone asks you what the article is about, you can answer them without reading the next 1,500 words.

---

No one really named it dual-track

Years ago, I was teaching a class with my friend Marty Cagan. It was really just my stuff and his stuff mashed together in a 3-day class. But, during my part I put up a model that I normally show when talking about how Agile thinking and product thinking work together in the same process. The model looked a little like this:

I’d hand-drawn my own version of the model, so it did’t look exactly like this. But, Marty asked me where this model came from. I opened the original paper from Desiree Sy (pronounced See) called Adapting Usability Investigations for Agile User-centered Design.

This is Desiree. You’d like her. She’s very smart.

Her 2007 article describes a common pattern which lots of people doing rigorous design and validation work in Agile development had already arrived at. Because, it’s really the only way this stuff can work. At the time, Desiree was working with Alias, now an Autodesk company, and she and her colleagues there had this working pretty smoothly. They were doing what most people at the time considered somewhere between super-hard and impossible. But, for them it seemed natural. Not easy, but it worked.

Marty asked me “what’s this model called?”

“It doesn’t really have a name” I said. “It’s just the way it’s done.”

“What does she call it?” Marty asked.

We scanned the paper and found this paragraph:

If I extract the important bit, it says

“… we work with developers very closely through design and development. Although the dual tracks depicted seem separate, in reality, designers need to communicate every day with developers.”

And that was it. Marty began using this term in his teaching to product managers. And since I often teach to the same people I began using that term. And gradually others began using that term.

Now I need to tell you I hate the term, and here’s why.

It’s Dual Track, not Duel Track

People just don’t read. It’s a miracle you’ve read this far yourself. Congratulations.

But people do look at pictures. And that picture of dual track seems to suggest different jobs for different people – like product managers and designers figuring out what to build, and developers building it. And in the worst of cases, you may interpret it as developers needing to wait weeks for product managers and designers to get their sh*t done.  It’s not supposed to be that way. If the whole team is responsible for product success, not just getting things built, then the whole team understands and contributes to both kinds of work.

I’d love a different term, and a different picture. But, I don’t have a better term or picture right now. Although I’ll try to draw a few more pictures to supplement this one.

There are two kinds of work, and there’s no way around it

Development work

If you’ve worked in Agile development before, you know teams will talk a lot about velocity. But the velocity they’re talking about is development velocity. Teams hand-wring about their predictability. At the beginning of a sprint, they’ll estimate velocity, and at the end they’ll measure it. Ideally their prediction was accurate.

When you’re delivering production quality stuff, quality is super important. If we’re putting software into production, quality, scalability, performance, localization, and lots of other concerns are important. So, finished development work should be built, tested, and reviewed by others to look after all these concerns. Agile teams will talk a lot about “potentially shippable software” which really means that they may not have built enough of it to ship yet, but once they do, the quality is high enough that they could ship it confidently.

Development work focuses on predictability and quality

Discovery work

One of the tragedies in software development, and all product development for that matter, is that much of what we build doesn’t succeed. It doesn’t deliver the benefit we’d hoped. So, that’s a problem. But, even before that, it takes a bit of time to learn enough about the problems we’re solving to make good decisions about what we should build. We use discovery work to do all that. To answer questions, to test ideas, and to avoid – as much as possible – wasting time over-investing in quality stuff we shouldn’t have built in the first place.

We want to learn as quickly, cheaply, and safely as we can. So velocity is important during discovery too – but this is learning velocity.

Discovery work focuses on fast learning and validation

Because the goal is learning, not working software, a discovery learning loop looks a bit like this:

It starts by describing:

• What we believe is the problem we’re solving and for whom
• The solution we’d build to solve it
• How we’d measure success

That’s our bet, our best guess, our belief, our hypothesis. All of those are uncomfortable words for people who believe they’re building the right thing. But, the truth is, we’re always making a bet that we’ll get value. Embedded in that bet are lots of assumptions, risks, and maybe some questions. To focus our learning, we’ll choose the assumption, risk, or question that scares us the most and identify an experiment or method to learn. Then do it. Then use what we’ve learned to change all those going-in beliefs about problems and solutions.

Sadly, one of the most time consuming and expensive ways to learn is to build potentially shippable software. So we don’t – unless we really can’t come up with any other way to learn, or we’re really confident our bet is good. Remember, we’re not betting we can build it on time. We’re betting that people have the problem we’re solving and will happily try, use, and adopt our solution.

The most expensive way to test your idea is to build production quality software

That’s how a learning loop works. And there’s a few things you should know about it.

We do all this as fast as we can. In hours when possible. Sometimes it may take days. But, we hope it doesn’t take weeks. So, lots of discovery learning loops should fit in a typical 2-week sprint.

Discovery work often results in killing ideas. At the end of every test you’ve got a decision to make: build it, kill it, or keep learning. Yes, what I’m really saying here is discovery work can and should result in killing ideas. Not everything goes forward. This can make some folks really uncomfortable.

We time-box discovery cycles. To keep discovery costs from running away from us, we’ll timebox a test or experiment from a few hours to a few days.

We can’t predict what we’ll need to learn next – not easily. When we learn something really valuable, it tends to really change our going-in beliefs, and really change what our next biggest assumption or question is. This can really suck.

Discovery loops chain together a little like this:

By now it should be clear that both development and discovery work are critical. But the mindset you approach the work with, and your process for doing it, are very different.

OK, it’s really 3 kinds of work…

To actually start building work software, you’ll need to make a lot of tactical design decisions. These may not be the risky decisions that need validation, but they still need to be made. It’s often designers that need to spend time ahead of development to refine and finish design work in preparation for writing code.

If you’ve validated the product is worth building, you’ll likely need to finish some detailed design work before you write code

It’s happening all at once

It would be super-cool if we could all focus on discovery work, get it done, then move our focus to tactical design and development. And that could work if all team members had the same skills. But since some are good at writing code, some are good at user experience design, and others are good at a variety of other things, we’ve got an opportunity to be doing many kinds of work at once. So we do.

Discovery work happens concurrently and continuously with development work.

I draw the conjoined model a little like this these days.

Discovery work uses irregular cycle lengths. It’s “Lean” in that we’re trying to make the discovery cycle as short as possible. Ideas in discovery mutate and very often get abandoned. The best move forward into more deliberate development cycles. I’m not sure how to show all that stuff in a single drawing. But, I’m trying to in the one above.

Discovery and development are shown in two tracks because they’re two kinds of work, and two kinds of thinking

Two tracks, not two teams

But, 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.

There’s usually more than enough discovery work to do and lots of ways to involve the whole team in doing it. If you feel pressure to shorten discovery work to “feed the beast,” it usually means you’re making decisions to build software before learning enough to be confident that you should. In the best case the outcomes are uncertain and usually the outcomes are just bad.

The whole team is responsible for product outcomes, not just on-time delivery

Busting dual-track myths

Let me hit the biggest misconceptions people have with the model again.

Myth: Discovery is a process that precedes agile development. It shouldn’t.

Discovery is a necessary part of product development. Practice it with the same agile and lean principles in mind.

Myth: All work moves from discovery to development. It doesn’t.

If we’re doing discovery right, we substantially change and kill lots of ideas.

Myth: The discovery team is different than the development team. It shouldn’t be.

While a product manager, designer, and senior engineer may lead and orchestrate discovery, they must Involve the whole team in discovery tasks wherever possible. Keep discovery work and progress visible to the whole team.

Myth: Once you move from discovery to development, discovery work done. It’s not.

This misconception is something that really bugs my friend Jeff Gothelf. He sees the production-quality software we build as our last-best experiment.

Keep measuring and learning even after you ship.

From Jeff Gothelf’s perspective, it’s all discovery and we learn from everything we make; be it a paper prototype, or the next feature in your production software. I agree with him.

There’s lots more to this story

I’ve talked conceptually about what discovery and development work is, and why you combine them in the same process. But, I’ve said very little about how you do this in practice. You should be feeling a little unsatisfied. Sorry about that.

But, this is the first article in a series I’m writing. Next articles will cover:

• How to keep discovery visible in a typical Agile process like Scrum
• How to adjust typical Agile planning, standup, and review meetings so they focus on both discovery and development
• How to think through your next best experiment and scale discovery investment along with confidence

What questions are you left with? What’s your biggest challenge doing any of this stuff? Please let me know what I should be talking about that I haven’t mentioned above.

Shameless plug

I teach classes in Scrum Product Ownership. But, they’re really classes about product management and design in an Agile context. Because, do you really need yet another class on Scrum? I’ve got upcoming classes scheduled with my friend Jeff Gothelf, author of Lean UX and Sense & Respond. The two of us tackle product thinking, discovery work, and this sticky dual-track stuff head-on. You should consider coming. Or tell someone in your organization that needs to understand this stuff about the workshop.

More Like This