Development In Product Release Context

This page started from FeatureDrivenDevelopment.

Features are the organizing principle for product releases. All groups coordinate around features and delivery dates. These are carefully negotiated and scoped.

For this reason development may create features in a continuous fashion, ala XP, but they can't be released continuously, they must be released on a coordinated feature basis. The reason is the complex context in which a "real" product is meshed.

A release must typically coordinate many groups: 1. Customers 2. Documentation 3. Field engineers 4. Manufacturing 5. Support 6. Marketing 7. Investor relations 8. System test 9. Groups working on future releases. 10. Lab managers 11. And more.

If your product is a word processor then your release process may be much simpler. But on a complex product a lot of groups must coordinate as well as any dance troup. The coordination is around specific features at specific dates. It does not seem possible to make a model of very small incremental releases work in this context.

Incremental development is not necessarily equivalent to incremental deployment. For a commercial product, you may not want to deploy more than once (or possibly twice) a year. Even here there are exceptions: software patches and sudden demands by big customers. Having an incremental development process where you always have a working baseline permits quick reaction and deployment for these situations. If you carry the incremental approach over to documentation and system test, you cut your time lag for deployment even more: develop a new feature, system test/regression test the new feature, write the documentation for the new feature. Your field engineers would probably gladly help walk a customer through a manual install or upgrade in return for quick response to customer problems. Your sales and marketing people would also love to be able to ship a solid, working beta version with a new feature to a customer prior to the next formal release. If you use incremental development, across all participants, you gain a huge amount of flexibility in determining when to have releases, but you are not required to have full or partial releases that do not make business sense.