On the surface, a Broadway musical, a newspaper, and software may not seem to have much—if anything—in common, but they have one common thread. All are delivered on a fixed schedule. But of the three, software tends to stray the most from the fixed schedule. In this week's column, Jeff Patton says that by focusing on the readiness of the entire product—as done in theatrical performances and when publishing a newspaper—and not just on the completion of the planned bits of work, you can produce software on a fixed schedule that you know is ready to ship.
The opening of a Broadway musical and the morning newspaper have something in common: They both deliver a unique product on a fixed schedule. So why is it difficult for us to do the same in software development?
While I'm no expert on journalism or theater, I know they do a couple things that we often neglect to do in software development, namely focus on the readiness of the entire product and not just the completion of planned bits of work.
I learned to apply the same kind of thinking working on software for brick and mortar retailers. These retailers often had hundreds of physical stores that ran our software. Each project had many risks. Could our software scale to hundreds of locations and millions of transactions? Could unskilled users quickly learn the software without much training or delay of business in the store? Our biggest looming concern was launching by Thanksgiving. If the project wasn't completed and rolled out by then, we'd need to wait another year. Retailers weren't willing to take on the risk of making major changes to their system during their busiest time of the year. They said, our "opening night" was usually sometime in October.
I learn the hard way, by making a mess of things the first time. But from this experience, I've designed three successful strategies that may help you decide if your product is ready to ship.
1. Understand the Big Picture and Focus on the Big Stuff
These days I use agile development approaches. I love the emphasis on breaking down work into small, deliverable pieces using backlog items or user stories, and then getting each done—really done—in a short time frame. But I know none of these little pieces by themselves make a shippable product. Lots of little pieces add up to big capabilities.
Similarly the morning newspaper is composed of lots of individual stories, many supported by pictures and each requiring writing, editing, and fact checking. But the paper is organized into sections like international news, local news, finance, entertainment, and sports—big chunks like that.
For software used at point-of-sale by a retailer, our product capabilities included "selling items," "returning items," "collecting payment," and "managing inventory"—big chunks like that.
The first step to finishing on time is to see the big picture of your product as a number of big capabilities. These may be obvious to everyone on your project but often aren't explicit. Get together as a team and decide what they are.
In agile development I use a technique called story mapping to organize my user stories into a big picture that's easy to explain and where all the small stories fall under a big capability or activity that users engage in.
2. Build the Whole Product Roughly to Start
Pretend you've just been cast onto a Broadway musical. Before you were cast, there was likely a script that divided the musical into scenes—the big chunks for a show like this.
In theater it's a bad strategy to start with the first scene, create all the costumes, finish all the sets, choreograph all the dance numbers, rehearse one scene repeatedly until it's perfect, and then move on to the next scene. They'd likely get the result I often see in software development, which is many bits of software completed well but major parts not having started at all. People would hate to show up for the big Broadway show and learning that the director has dropped the last two scenes of the musical in order to finish on time.