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