Fallacy of a shippable product

The agile literature generally advocates a potentially shippable product at the end of each sprint.  I find this assertion problematic.  It is disconnected from the larger discipline of product development and somewhat naïve.

The fallacy lies in the fatal (and unstated) assumption that the product is programming, testing, and documentation.  It isn't.  While these are the basis for the end user experience, they do not represent the totality of the experience.

For example, the customer may need help and call support.  Or, the customer may need help implementing the software and require training and services.  You may not even have a customer, and therefore require someone to market and sell the software.  All the coding, testing, and documentation in the world isn't going to solve these challenges.

Here are some of the other groups needed to make a product shippable.

• Sales requires knowledge of the problems the software solves in order to position it to the buyer.  They need assistance learning how to demonstrate it effectively.  They will also need to determine the price of the software.

• Marketing must understand the features, what they do, the problems they solve, and the benefits they provide to the customer.  They may need testimonials or other endorsements. They also typically develop collateral, press releases, and other material that can be "left behind" by sales or used at trade shows.

• Support must be trained on the use and troubleshooting of new features. They may also need to learn new issue escalation paths to development for issues that exceed their skills or knowledge.

• Services will need to learn how to install, upgrade, and configure the software.  They may also be the group that trains users, as well as consults on best practices for using the software efficiently.  They will need to develop end user training and consulting guides.

• Legal will need to draft contracts that can be used when the software is purchased or licensed.

This is a significant list of deliverables required to ship a product to an end user. Are you really going to have your organization do this in conjunction with the end of every sprint?   The cost associated with these type activities is best spent once, when the release is stabilizing towards the end of the remaining sprints.

Continue to strive for fully coded, tested, and documented software at the end of each sprint.  But let's mature our view of product development and recognize it is much more than just the ones and zeros.