Related: XpConceptsInAcceptedMethodologies
----
I have this friend who helps perfectly reasonable clients to write healthy projects that frequently deliver to profitable customers.

In an XP-free environment.

Now sort this list in order of impossibility to talk any Waterfall or Iterative project lead into:
	* PairProgramming
	* OnsiteCustomer
	* ContinuousIntegration
	* FortyHourWeek
	* Simple Design + RefactorMercilessly
	* CollectiveCodeOwnership

The rest of the sermon (UnitTest''''''s, short releases, PlanningGame) are just an enlightenment thing, and have been around under other methodologies.

My friend feels that, for everything he reads on these and related resources, he just needs to order everyone he works with or knows or meets on a bus to just read the same resource. But my friend has seen TV documentaries about what typically happens to those who try to start and spread new religions. My friend has made a policy of not getting lynched at work, and this commitment has generally achieved positive results so far.

Where to start?
----
One idea I am going to try is starting a skunkworks project -- you can't argue with results, and you should get results if you can get high-level sponsorship for a project that has well-trained, committed individuals, a supportive, committed customer, and a project with medium risk and medium visibility.  I announced a couple of discussion groups to the systems organization in an attempt to find others interested in or intrigued by XP (I included a brief description and said this stuff resonated with me), and 7 people showed up.  Then I started a wiki-like discussion group on LotusNotes using the Journal template, and now I have a group of about 10 interested people (mostly developers).  I hope to attend the ObjectMentor training in February, and then hopefully I can get a skunkworks project going soon thereafter.  RonDagostino

----
Those having trouble with the Epiphany angle review case histories here: HowYouWentExtreme.
----
''Where to start?''

I'll take that as a serious question. Pick the most important, as DonWells aptly points out. Then do experiments.

Measure points accomplished, including defect rates, when working heavy overtime and when not. Do what the numbers suggest.

Work together a while, then separately. Again measure progress and quality. Do what the numbers suggest.

Measure time to get answers via email and phone mail when the customer isn't present. Schedule a meeting with the customer, ask questions, measure the time till you get answers. Do what the numbers suggest.

No need to be fanatical, even if I am. Just steer a bit and see whether you go faster on the road or in the gravel.
----
I have this friend who helps perfectly reasonable clients to write healthy projects that frequently deliver to profitable customers. Where to start XP?

''Don't. They don't have a problem. Don't solve it. -- KentBeck''
----
CategoryExtremeProgramming