When Can We See the Ocean? Defining and Setting Iteration Goals
Software development teams think of their projects in technical terms, such as task difficulty or code dependencies. But in Agile development, when we deliver features in iterations, it’s important to remind ourselves to give the users some of the things they’re longing for, sooner than later.
Growing up, our family vacations were few and far between, but they often involved the ocean – or at least, the Gulf of Mexico. In those days, when the only in-car entertainment was license plate bingo or fighting with siblings, we were all eager to get where we were going. Mom and Dad had not traveled far down the road before we kids started asking, “Are we there yet? When can we see the ocean?”
I imagine that business stakeholders feel the same way about software projects. They’re in negotiations with a potential partner, and if they had features X, Y, and Z, they could land the multi-million-dollar deal. Naturally, they’re going to start asking the software development team, “When will we have that feature?”
What if my parents could have provided small sections of the ocean experience as we drove? Perhaps soon after we hit the freeway, lovely salt air would start blowing through the car. A bit later, we begin to hear the sounds of crashing waves and seagulls. After a while, we can see blue water through some magical telescope. Crabmeat materializes to provide us with a culinary experience. We could enjoy all these features of the ocean long before we actually arrive on the beach.
We can learn to divide software features into small chunks that provide our stakeholders with portions of the functionality they need. By working incrementally and iteratively, we can keep our feedback loop short, learning quickly if what we’ve delivered so far doesn’t meet business needs. It’s not so bad to fail when we fail fast, and apply what we’ve learned to future development. Our short iterations and thin slices provide milestones to help us stay on track. We won’t know exactly how far we are from the ocean, but we can identify and avoid traffic jams and road closures.
The Big Picture
Though we developers work in small chunks, we always have the big picture in mind. And here’s the news: We don’t necessarily have to deliver every single piece of that big picture.
As Janet Gregory points out, when you’ve filled in the most interesting parts of a jigsaw puzzle, those vast areas of sky or grass may not be needed. Customers want the most valuable parts of the feature. A long-distance view of the ocean may fulfill their needs. They might not need every grain of sand on the beach.
How do we define which parts of the picture are truly essential? Before we start writing code, we must sit down with the stakeholders and discover what they need. Story mapping, mind mapping, paper or whiteboard prototypes, Wizard of Oz testing, any way we can think of to capture examples of desired and undesired behavior helps.
Prioritize the parts that absolutely need to be there for the feature to be useful. If customers resist the idea that they won’t get 100% of their feature picture, ask them: “Would you rather have 80% of the functionality you need, fully working? Or would you like 100% of it present, but none of it is actually usable yet?”
In other words, will it really work to drive 80% of the way to the beach?
There are always workarounds for the low-priority components that don’t get coded. Customers often prioritize speed of delivery over a comprehensive feature set. They want to start using the most critical features as soon as possible.
Focus On the Business Goals
In real life, it might be hard to deliver just part of being at the ocean. However, the benefits of the beach experience might be delivered without having to drive all the way there.
When I was a kid, what did I really love about getting to go to the beach? In hindsight, it was the chance to have a long, relaxed period of time with my parents, experience something new, eat some delicious junk food, and (of course) play in the ocean. The sand in my swimsuit at the end of the day was not so pleasurable.
My husband and I now have designated “Beach Days” at home. When we’re “at the beach,” we aren’t allowed to do housework or cook. We can only do the things we might do at the beach: relax in a lounge chair in the backyard, eat yummy and not-necessarily-healthy prepared food, and enjoy a glass of wine while watching the sunset. That fulfills our need for a day of total relaxation and fun.
By spending time to learn our company’s (or consulting client’s) business domain, and understand the true goals of the business stakeholder, we can often suggest alternative ways to meet their goals. When the product owner comes to your team with a complex feature the business needed “yesterday,” ask her to explain the purpose of the feature. Techniques such as story mapping can help both the customer and developer teams achieve a shared understanding of what’s needed.
Then think about how to achieve that purpose in a simpler way. Perhaps you can leverage features already in the software to do something that meets 90% of the business goal at half the price of the complex implementation. In my experience, the other 10% turns out to not be so important!
Don’t get obsessed with “defining done.” Take time to learn the jobs of business stakeholders, and their business objectives. Work with them to understand the true purpose of each new theme or user story. Practice slicing features into small increments so that something is ready to use at the end of each short iteration. Of course, there are many details to verify, but don’t forget to test the big picture, and make sure the software solves the business problem.