Friday, June 13, 2008

Time to Market

It's baaaaaak!. Every so often the Time to Market monster raises its head and the village chiefs start to point and run. "We need to improve our time to market/profit/customer/engagement/yada/yada/yada!" I'm not suggesting that we don't need to decrease the time it takes to bring new features, products, or services to our customers; quite the reverse - we absolutely need to deliver more, faster.

My concern is twofold, first is that Time to Market is addressed as an afterthought. After we've determined the requirements, the resources, the tools, and the cost, we decide to add (like its an ingredient) development speed. (We also do this with quality - "Hey let's make it high quality while we're at it"; but that's a subject for another time.) Development speed is not something that can be *added* to a project, a team, or an organization. It is something that happens; when the project, the team, or the organization has acquired predictability in their development process. More on that later.

The second issue with the cyclical Time to Market mantra, is that we already know what it takes, yet every couple 'o years we do the "focus group" thing to discover how to improve our development speeds. Sigh. Imagine the U.S. Postal Service in the early 1800's, i.e. the Pony Express riders. These people transfered mail from town to town, like a giant rely race on horseback, riding as fast as they could. Improving delivery times generally meant beating the horses more, getting bigger, stronger horses, and riding them longer. Even with all of that, you could only eek out so much speed.

Along comes a visionary who says, we could transfer the mail faster if we built a railroad. The Pony Express Riders have their doubts because to them, with the wind at their face, the mail is moving as fast as it can, and besides it will take too much time to build a railroad. Railroads require too much construction, too much structure, AND you loose flexibility. Trains can only go where the tracks are. Jump ahead a hundred years and airplanes are used to move the mail. Consider FedEx.

The system used by FedEx is a marvel to see. Every night hundreds of airplanes, big ones like Boeing 747s fly into Memphis, Tennessee where all of the packages are offloaded, sorted, reloaded and flown out like a giant lung inhaling and exhaling. On an average day FedEx brings into and out of its Memphis SuperHub three million packages. On December 22, upwards of five million. All of these will be delivered within twenty four hours. The processing facility is capable of handling 500,000 packages per hour, 325,000 being small packages, 160,000 being boxes, and the remainder being large or oddly shaped.

Here is a graphic that shows the FedEx aircraft over a 24 hour period flying into and out of the Memphis SuperHub:



Now let's consider those statistics in relation to software development. FedEx is arguably one of the most efficient organizations in the world, as evidenced by the number of packages they deliver overnight. You can't get much better "time to market" than overnight! And yet less than 3% of what they handle is "special cases" - large or oddly shaped. They have created an infrastructure whereby 96%+ of their requests can be handled by the infrastructure with little to no special handling.

This is the secret (not that it is a secret) to improving time to market. Create an environment where only a small fraction of your user's requests need to be treated as special cases. How? Just follow these rules:
  • Know the business - putting the developers, or at least the designers and testers inside the business is a significant improvement.
  • Use Agile/Interative/SCRUM/eXtreme/Shorter methodologies and cycles - don't even plan for a 6 month development project - you'll never get it right (See Standish Group CHAOS Report)
  • Limit the solution sets - have predefined architectures, server configurations, hardware choices, UI standards, etc.
  • Build, maintain, and enforce reusable libraries - dedicate a very small team to identifying code modules, objects, and patterns and do not let newbies re-invent the wheel.
  • Tools - integration is more important than functionality; spend the time and the money to allow work to seemly flow from one set of tools to another.
I'd like to say that one of these is key, sort of a Golden Rule, but each brings separate and distinct value. Do them all. I would add that these are also key ingredients (did I just say that?) to improving software quality.

No comments:

Post a Comment

Follow by Email