It’s MAD to Have a Separate Discovery Phase

Here we are with another Misadventure in Agile Discovery (MAD). This one pairs well with the first misadventure, the separate discovery team. Even when that mistake is corrected and a balanced team is working together through discovery and delivery, the team may decide to spend some time furiously creating a slew of new ideas.

Bananas

Bananas by Pin Add

After all, ideas are cheap and easy to come by. Bananas are cheap, too. And like bananas, ideas are perishable and have a short shelf-life. If an idea is valuable because it’s widely used, it’s best not to let it rot on a shelf. Most people don’t want to eat a black and mushy banana. Yuck!

How can a team keep their bananas, I mean their ideas, from going bad? If it’s a Scrum team, one way to help keep both the discovery and development tracks moving in parallel is to include discovery in the Scrum ceremonies. One of the problems might be this notion of dual-track development. No matter how it’s described, some people believe that we work in one track, and then the other.

Mountain Bike Macetown 4WD Road, Queenstown, New Zealand

Mountain Bike Macetown by Trailsource.com

Warning! Another analogy! Have you ever heard the term dual-track (or double-track) in relation to mountain biking? It means a four-wheel drive trail. Notice that both the tracks cut through the ground all the time. Can you imagine driving a Jeep off-road on the left tires for awhile, and then switching to the right? Then you must be a fantastic stunt car driver.

It’s like the Lean Startup’s build-measure-learn cycle. Or maybe that should be measure-build-learn. Or maybe something is missing. In any case, all of these steps are parts of discovery. Then again, measure itself might be the only part of discovery. Ideation and experimentation are fine, and it’s the direct observation of results and understanding the outcomes that really help us learn if those ideas are worthwhile.

The concept of this Lean Startup cycle is to go through it as fast as possible. There are so many benefits and needs for speed. I’ll add another. Rapidly invalidating assumptions and getting rid of ideas. A majority of ideas won’t pan out, just as a majority of software is hardly or never used (PDF, pg. 6). Talking with a few different organizations that measure this, somewhere north of 60% of ideas aren’t worth building.

I recently asked a CTO, why do you want to have discovery covered by the Scrum teams? He told me that he had an innovation department of about twenty people, and over two hundred people in engineering. In this way, he said the organization could fail faster, easier, cheaper, and in different ways on their path to successful innovation.

Fresh Tracks

Fresh Tracks by XKCD

There will be times to invest more in discovery, or delivery. Oh boy, Yet Another Analogy. YAA! In downhill skiing, both skis make parallel tracks, and weight is transferred from one ski to another in the turns. Over 90% of the pressure is on the outside ski in the heart of the turn. Turns are made frequently. And a skier goes the fastest when both skis are pointed downhill.

A team might want to invest 90% in discovery or delivery, and may go the fastest if overall they balance the investment in both. Be careful of investing 100% for too long. The team might wipe out.

Are your teams attempting to be involved in both discovery and delivery? What challenges have they encountered, and overcome? What’s proven to be successful? I’d like to hear from you, too.

This entry was posted in #agile explained and tagged , , , , . Bookmark the permalink.

2 Responses to It’s MAD to Have a Separate Discovery Phase

  1. I have noticed that one challenge often faced by teams integrating discovery into their process is that engineers on the team may feel they have nothing to do during all this squishy talking to customers.

    Some engineers may take to it quickly, having done their own startup and realized that they don’t want to produce code before they have found a valid need. But even then, the urge is to build something and they won’t be 100% satisfied if they don’t get to spend some time coding.

    So I like your skiing analogy. It’s never good to focus 100% of the time on one or the other for too long. The team may indeed wipe out.

    • Aaron Sanders says:

      Hi Tristan,

      Thanks for your comment. I agree that some engineers may feel there’s nothing for them to do during all this talking to customers. And I try to encourage them to try it, all the same. I like Dan Mezick‘s take that this culture game should be opt-in, so that means I don’t force the issue. For instance, one engineer would go out, and was only comfortable in the observer/note taker role. As I noted in the misadventure of the separate team, I’ve heard so many fantastic comments from engineers who started skeptical, and wound up fans. It seems that watching a user struggle with a product can be humbling, yet invigorating.

      Thanks,
      Aaron

Leave a Reply

Your email address will not be published. Required fields are marked *