If you have access to the TV show "StarTrekDeepSpaceNine", study the culture of the species called "Ferengi". Their natural instincts revolve around mercantile and financial dealing. They pay money to visit someone in their house, or to have a conversation with a government official, or to worship their religion. Their officers pay their soldiers, per order. Their childhood games revolve around gambling and simulating stock markets.
They don't have wars. They sometimes have financial collapses; these rally them to the cause. Their only serious crime pattern is kleptomania.
An XP team works by pretending that it is payed per story. The team behaves as if the OnsiteCustomer took bids in "ideal days" or "complexity points" for each story, paid for an iteration, and at its end collected new program features that add value. They are expected to behave like Ferengi.
They do this because it's not pretending. The OSC invests real money in running a programming team, and expects a continuous return on investment. They should be able to cancel the project at any time, no love lost, and get back a working product expressing exactly the value of the money submitted into the system.
Strict code ownership would interfere with return on investment. Programmers without trust cannot efficiently fulfill their "contracts", which are the user stories they bid on.
In an economic model, programmers cannot simultaneously own source code, and own user stories. That would cause incredible friction. Hence, programmers own the UserStories, and the OnsiteCustomer owns the code.
--PhlIp
The Ferengi Rules of Extreme Acquisition:
Duplicating them probably violates Paramounts copyright or somesuch, but since someone else has already done this, I'll take advantage of the fact:
http://www.psiphi.org/DS9/rules.html
Here are some that I think are especially relevant to XP:
(Do the Stories with the most value first.)
(DoTheSimplestThingThatCouldPossiblyWork.)
(Communication. Don't leave things implied.)
(Anything worth doing has an acceptance test for it.)
(If your work isn't delivering business value, you might as well not be working at all.)
(If the Customer isn't steering or driving, the Customer won't necessarily get what they want.)
(RefactorMercilessly. Including code other people have written.)
(Courage. Have it. Everything else will follow.)
(There's nothing more productive than an honest team. They're likely to get the most done.)
(Don't throw blame. Solve problems instead.)
(Never confuse code with no tests with code that's correct.)
so.
(You get what you measure: measure only success and reward the team when they deliver it.)
(It is easier to ask for forgiveness than permission.)
(Applies without translation, except for the use of the word "latinum".)
("Play to win. Don't play not to lose." -- Beck.)
(If you never get to ship your product, then your project doesn't count. Gear your process to ship regularly.)
(Similar to #106.)
(Even for the most doomed of projects, people like Wyatt Sutherland can turn them around. Learn to be like Wyatt.)
(SustainablePace. FortyHourWeek.)
?. It's better to live on one's feet than to die on one's knees.
(It's better to have Done The Right Thing and have the project go tits-up than to cave in and do things you think are wrong and have the project turn out the same way.)
-- DossyShiobara , from the XpMailingList