Extreme Programming For Products

A lot of the XP practices, and in particular the PlanningGame seem to have an in-house feel. The successful XP projects described on Wiki are such. These kinds of project have one customer "business", and the binding between the developers and the customers is direct, their contracts of employment with the one "business". There is one source of UserStories, and no inherent barrier to communication (the people involved may screw this up for other reasons).

But much of the world's software is produced by product companies, not in-house IT departments.

In such a case, the "business" that employs the developers is a conduit between the developers and the real customers, the licensees of the product. The binding between the developers and customers is indirect, via the developers' employment contracts, and the company's product licences.

Typically, a product company aims its products at a given problem domain (maybe there's another challenge to do with GenericShrinkWrappedProducts?), this means that each pair taken from the set of clients will probably be a pair of directly competing companies.

Does the PlanningGame now need modification?

Are UserStories elicited from the many customers directly, or via the business? How are priorities decided between the overlapping (possibly conflicting) needs of the various customers? Would you need competing customers to discuss their requirements with each other? How could "business" balance these needs otherwise? (and without violating any non-disclosure agreements that may be in place).

This balancing act is something that many product companies get very wrong. How could XP help them?

Maybe a solution to this would go in ExtremeMarketing

There seem to be two possible business situations- one where you have a few customers, each of whom accounts for a large percentage of your revenue,(FewLargeSlices?) and one where you have many customers, each of whom accounts for a very small percentage of your revenue(ManySmallSlivers?). Which one would you like to ask about first?

Which would you like to answer first?

As a long-time developer of software products, I have used the following tactics to commune with customers:

Special interest groups of customer represenatives who are interested in particular features.

Getting customers to help develop business models for functional testing.

Piecemeal growth development (somewhat XP like) where small standalone or incremental features are sent out to customers for beta testing. This tactic requires that you always develop some useful increment.

On those projects when I have not had constant, ongoing conversations with end users about the software I am developing, the software features always went astray, in terms of fitness for use, missing features, or features that nobody wanted.

Most of my development experience has been in software product companies. These companies rarely lack for marketing and sales people who [are supposed to] know what the customers want. In fact, generally they do know pretty well, in my experience.

Where things go wrong is in asking for everything by some specified date. This requires the developers to kill themselves, and results in various fights about what can and can't be done.

My experience, much of which has been highly successful, and none of which has lead directly to the death of any humans or animals, tells me that the PlanningGame will work just fine with Business = Sales/Marketing and Developer as usual. By informing Business on how long things will take, we can enable them to make better decisions on what to do. Sales and marketing folks are generally pragmatists. They can make tradeoffs in the space of the possible quite readily, given the necessary info.

Will their decisions be short-sighted by my techie standards? Sure. But what I've learned from XP (besides human relations skills, thanks for asking) is that my techie standards don't generate ROI as rapidly as they might. What I've learned going down with a few ships is that ROI is what keeps you employed in a product company. The testing and refactoring practices will keep the system flexible enough to survive. --RonJeffries

In addition to sales and marketeers, consider adding real end users to the team if at all possible.

Marketeers often focus on whatever missing feature they thought made them lose the last sale; prospects often ask for things that they read about in a magazine; and when the marketing people do know what features are required, they don't know in sufficient detail, so the programmers still need to make guesses.

A scenario that I have seen work well is for the marketeers to select features with a broad brush, and then select end users to talk to the developers to refine the features and help develop functional tests.

Marketeers select and prioritize features, end users refine features, and developers estimate and code. --BobHaugen

Do we have any SuccessStories? from SoftwareHouses? using XP for ShrinkWrappedProductDevelopment?, though? Or is applicability of XP to such development still just a theory, with actual success stories all concerning InHouse? development? --AlexMartelli

But much of the world's software is produced by product companies, not in-house IT departments.

According to EricRaymond 's TheMagicCauldron, however, 95% of software is written InHouse? (http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron-3.html); this makes the 5% of us that are writing ProductSoftware? freaks, I guess... --AlexMartelli

The two statements are not incompatible; in-house software gets used by a few hundred or thousands of people. Productised software gets used by hundreds of thousands to millions, typically. So, while most software is written for in-house situations, most of the software that is used is productised.