I don't think you need Iteration Zero. "Iteration Zero" is the idea that you should spend the first several weeks of a new Agile product setting up technical infrastructure, gathering requirements, and so forth. I don't use it because I know you can start working on a new product right away, with no Iteration Zero or other up-front planning phases, and deliver business value by the end of the first week.

I know this because I've done it--several times. I just did it again today with my latest Immersion client, and I want to share with you how it works. The trick is to use tiered planning horizons and incremental design and architecture. In this essay, I'll focus on the planning side to show you how we got started--from zero to coding--in just two days.

We did need to get a few ducks in a row ahead of time, but perhaps not the ones you expect. We made sure we had:

• A Whole Team dedicated 100% to our new product.
• Real business experts playing the role of customers on the team.
• Compelling business objectives, although perhaps not entirely clear or agreed-upon.
• A open workspace with furniture in place, although much of the hardware is yet to be unboxed.
• A brand-new product with no pre-existing code.

What We Did

Early Morning, April 13th: Agile Overview

I provided an overview of my approach to Agile, starting with the roles on the team and a look at the Agile lifecycle. We discussed the implications and I answered questions for a while, and then I introduced our planning approach and the components of the product vision.

Late Morning and Early Afternoon, April 13th: Vision

We had two of our four customers present. I asked them to talk about their strategic goals for the product, and right away it was clear we had some disagreements. Our experts didn't share the same terminology and weren't in agreement on all of the goals. We spent a few hours sharing perspectives, then broke for lunch. The customers took advantage of the break to talk a bit more without an audience. After lunch, we summarized the various goals without trying to reach consensus.

The other members of the team listened and asked a few questions. Afterwards, they mentioned that hearing the discussion and differences of opinions helped them understand the situation better.

Late Afternoon, April 13th: Minimum Marketable Features

I thought that looking at concrete features could help clarify the product vision, so we moved on to minimum marketable features (MMFs) without working on the "Why" or "Measures" portion of the vision. By this time, our third business expert had joined us.

I introduced the basic idea of the MMF: the smallest thing you can do that has value in the market. The customers brainstormed dozens of ideas, then prioritized them. The programmers estimated the top 20 or so using rough, gut-feel t-shirt sizes, and we ended for the day.

End of Day, April 13th: Terminology Discussion

The MMF discussion hadn't really rung true for me. There were a lot of features discussed in that session, but they didn't really look like they were marketable. Also, during the discussion, the idea of a "prototype" kept coming up. Many of the MMFs were listed twice: once as "Demonstratable" XYZ, and again as a "Functional" XYZ.

After the last session, I talked with the business expert that was most strongly in favor of prototypes. During that discussion, I discovered that he didn't mean a prototype in the sense that I use the term. He meant that he wanted to focus on getting a broad cross-section of features in the application quickly so salespeople could start showing it off. From this conversation, we realized that the real early MMFs for this brand-new product were things like "road-show" and "client confidence."

Morning, April 14th: MMFs Revisited; Stories

The next morning was very productive. Armed with the insights from the previous evening's discussion, the customers quickly created a dozen new MMFs, each clearly aligned toward a specific market objective. We didn't bother estimating them this time--the priorities were obvious, and didn't depend on sizes.

Next, the customers created stories for the first MMF. They brainstormed half a dozen stories, but then moved nearly all of them to a later MMF. With a clear statement of market value in front of them--and an unmovable date for achieving that value--the customers realized on their own that a laser focus on doing the minimum to meet the MMF was most important. They ended up with just one story.

I introduced Agile estimation and asked the programmers to estimate that one story. It ended up being too big for a single iteration, so we talked about how to split stories--which the customers then did. And did again. And again. We ended up with about 10 stories split out from that one original idea. We were able to estimate the five most important before lunch.

Afternoon, April 14th: Iteration Planning

After lunch, we picked the three most important stories for the team to include in their first iteration. We think the team will be able to do more than those three stories, but it was a good starting point. While the programmers tasked out the stories, the customers continued working on the MMFs and stories. By this time, the customers were keenly interested in the nascent product roadmap that was taking shape.

As the programmers worked on their engineering tasks, they came across some questions for the customers. That interaction was a bit rough--everybody needs a bit more practice in learning to communicate effectively. I talked about using a set-based approach to share the range of cost-related options (for programmers) and value-related desires (for customers). By using a set-based approach, I explained, you can choose the intersection of the two sets that provides the most value for the least cost.

The iteration planning went smoothly--the programmers understand the domain well, so there wasn't a lot of the usual confusion that I typically see at this stage. They broke the stories down into engineering tasks and also identified several global tasks, such as "set up pairing workstations" and "configure version control system," that are necessary for them to get the stories done.

We wrapped up by deciding what day we wanted our weekly iterations to start on, and that was it! We start development work tomorrow.

The Moral of the Story

We didn't finish anything we started. We didn't need to. We did do enough work, from product vision to engineering tasks, to give us a very solid plan for starting this first iteration.

The trick we used was to get just information at each stage to allow us to continue to the next. We did just enough product vision work to clarify our most important strategic goal. We did just enough MMF planning to understand what is really marketable for this product, and to identify the most important marketable feature. We did just enough story planning to start iteration planning, and we tasked out just enough stories to keep us busy for the next few days.

There's a lot of work left to do, and that's what the customers will be working on while the programmers are getting started. They'll make sure the programmers have enough stories to work on during the rest of the iteration. They'll review and update the MMFs that make up the product roadmap, and start brainstorming stories for the next few MMFs. And finally, once I can get all the customers in the same room in a few weeks, we'll finish our first draft of the product vision, using the concrete information that's we've gained from creating MMFs and stories to help resolve the disagreements and terminology issues.

I don't use Iteration Zero, and I don't think you need to, either. Perhaps the way I do it is an advanced technique, but I'm not so sure that's true. What's definitely true is that starting a new product is a bit scary. There's this churning mass of unknown rippling below you, and it's tempting to sit on the edge of the pool and try to figure a bunch of things out before you start. But I prefer to dive straight in. Doing the work will help you understand the work, and the iterative refinement that follows will help you get better results more quickly.