I read XP Explained a little over a year ago, and found it very interesting. I agree with most ideas, in principle. However the idea as a whole is "counter-intuitive" given the predominant software culture. It's not what people are used to doing. This led me to the following questions: 1) What is the start-up cost? How much time does it usually take for a team to abandon it's old ways and really do XP. I imagine an abrupt transition is easier than slowing adding in XP ideas (or is this not true); if so, there is surely some learning curve. What is it? Is it different for different sized teams? 2) How exactly do you go about starting with XP? It's the actual implementation of XP which seems like the hard part. 3) How well does XP scale? It seems great for teams of 5, even maybe 10 or 20 programmers. How does it scale to 40, or 100? if you break down the 100 or so into smallear teams, say 10 teams of 10, each using XP, how do the 10 teams coordinate under the XP process? 4) Eric Ryamond's wisely reconized that convincing programmers of OSS (Open Source Software) is one thing, convincing management is quite another. In his book The Cathedral & The Bazaar he includes sections on how to convince management. Mr. Fowler, do you have any such similar advice for XP?
1&2) Certainly it's most effective to go whole hog to XP, but for most people that change is too hard. So they go gradually. Continuous Integration and Testing are good ones to start with, as is the planning process. I have no idea how to quantify the ramp up curve, but you can get paybeck from these things pretty quickly. 3)I don't reccomend using XP with more than a dozen developers, nor with a distributed team. Many of the practices are still useful, but the whole package is designed for a co-located team of up to a dozen in size. 4)I do my best, but I'm just a geek :-) For more on this you might want to look at the XP mailing list: http://groups.yahoo.com/group/extremeprogramming/