Are You Ready to Ship?

The theater trick is to rehearse the whole musical performing and perfecting each number-starting without sets, costumes, or a full orchestra, then adding and improving those things over time. On opening night we're not aware that the costumes could have been better given more time, or that the sets were missing parts that were originally planned. To the audience, the whole thing is complete. We'd never know that in scene four the lead actress was supposed to be wearing a big feathered hat that didn't get finished in time—unless someone who knew the original plan pointed out the "missing scope."

By applying this strategy to software development, we'd focus on building every major capability of a product to a level that wasn't ready to go live but was complete enough to show what the whole product would look like. In an agile environment, I slice stories thinly, back to the raw basics that allow me to see the software working, but not ship it. This is the Broadway musical version of performing the scene on a bare stage dressed in a t-shirt and jeans. Once I can see the whole product at this level, it's time to begin building it up by adding more thin slices to each capability of the product, thus, improving it all.

3. Routinely Assess and Improve the Product's Shipability
Now pretend you're the director of the Broadway musical. The producer phones you a month before opening night and asks you how things are going. If you answer: "We're done with 16 of the 20 scenes," you'd better start looking for another job. What the producer's looking for is some idea of how successful the show is going to be. It's about what happens after opening night. The producer doesn't care that the hat for the lead actress may not be done prior to show time. He only cares if it affects opening night reviews.

In software development we pay a disproportionate amount of attention to the output (the stuff we build) and not enough attention to the outcome (the benefits we want). In agile development, one of the most common ways to assess progress is using a burn-down chart popularized by the Scrum process framework. It's a simple chart that shows how many items we have left to build at any time. Watching the slope of the line showing items built over time tells us how fast we're building. The one thing it can't tell us is if people will like the software when they get it-if the outcome will be good.

In Scrum, the person or people filling the product owner roles are ultimately responsible for a successful product. Like the director of our musical or the editor of the newspaper, their work will be applauded if the outcome is good. Ultimately, the product's success relies on everyone doing well. If you're a scrum product owner, you can help everyone understand how likely success will be with a routine release readiness assessment.

Release Readiness Assessment Recipe
A release readiness assessment keeps the subjective quality of your product visible. The product manager or product owner, supported by a team, performs an assessment every week or two. To do this:

• Gather a small working group who understands the product, and can define success after delivery.
• For each of those big capabilities of your product, consider the product's consumer. Consider what their life will be like after the product's delivery. Will they be unhappy, satisfied, or ecstatic? Together as a product team, discuss and decide on a grade to give the functionality as it stands right now. Try using a letter grade the way US school systems do. A capability that's satisfactory but not fabulous would get a "C." One that won't work at all for its intended audience would get an "F."
• With this current report card of your product, communicate the grades to the entire team. Discuss your plans for the next round of work with the goal being to improve the current report card.