Xp For Products

With this I mean ExtremeProgramming used in a project where a product is developed, that will (hopefully) be used by different people in different situations. See XpModes. --MarnixKlooster

So some potential users need certain options, others don't, and it is difficult to define the requirements up front. There are many trade-offs, dependencies on market trends, etc. Makes it difficult to write down and prioritize your UserStories.

We don't do full XP (altho we have been influenced) but we do software products. We get as many user stories as we can from customers and prospects and then do commonality and variation analysis as in JimCoplien's MultiParadigmDesign for C++ book. The book describes the technique for design features, we use it for user-features. Priorities depend on a combination of common wants, market analysis and who is likely to be the first live customer for this stuff. -- Bob Haugen

Q: Should 'product projects' use XP?

Since XP was created to address a specific area of risk (that of rapidly changing requirements), would it make sense to adopt XP if that is not the primary area of risk? If we are developing a product, we have to gauge what the most usable solution for the greatest number of customers will be; presumably this is not as unstable as being responsible to a single customer. --KayJohansen

I've probably worked on to many 1.0 products, but in my personal experience: There may be a most usable solution out there and it might even be stable, but your team's best understanding of what that solution is will vary drastically from day to day. -- CurtisBartley

Been there too -- and not just on 1.0 projects. I have spent the last eight years working on products, not solutions, and have seen plenty of changing requirements. I am still not convinced, however, that this is the number one risk for products, the way it is for solutions. What do y'all think -- are the risks different depending on whether you're developing solutions, products, or languages/libraries? --KayJohansen

Q: Can 'product projects' use XP?

Since XP is based on close interaction with a single customer, can it be made to work in a 'shrink-wrap' development shop, where there isn't direct access to a customer or even if there is, multiple customers have conflicting requirements? --KayJohansen

The "customer" in XP isn't a person who buys the stuff, it's a person who translates the requirements and the business value of the requirements into a plan. In a product situation, it's generally "Marketing". In an entrepreneurial situation, it might be the person with the vision (though often they have trouble setting priorities). XP would be your best chance.

As an aside, if the proposed customers in fact have ConflictingRequirements, you aren't looking at a product. You're looking at trouble.

If I ever do another product (I've done literally a half-billion dollars worth), I'll use XP. --RonJeffries

So -- my gears are turning here -- if we treat this position (Marketing/Product Management/Product Design) as the customer, would it be an oversimplification to say that XP applies to product development in every way the same as it applies to solution development? --KayJohansen

My original point was not that one shouldn't use XP for products, but that the details of the XP process probably differ for different goals; I called this XpModes.

As an example, there is some XpChallenge? <please help me out here> that talks about developing a software library, and how that's different from developing --say-- a payroll system. Such a library is what I would call a product (or perhaps a language -- see XpForLanguages).

One specific difference is that for a product or a language, one (at least I) needs the concept of a StoryIdea: a requirement or idea that is so vague that it cannot yet be turned into a UserStory, but which needs to be captured and planned.

--MarnixKlooster

It's not XP, but see FreeHandProcess for a description of how one product is developed.