Borrowed from JamesGoebel's post on the XpMailingList (http://groups.yahoo.com/group/extremeprogramming/message/43372):

If you push XP you will receive resistance. Instead I would suggest that
you start documenting key metrics that every process must perform. If you
can get everyone to agree to those, then you will be in a better position to
argue that XP is appropriate later.

For example...
	* All production code must have unit tests.
	* All developers must run the entire suite of unit tests every day.
	* All unit tests must pass before and after code integration.
	* All production code must be signed off by one peer. That peer is signing up to have that code be part of their annual performance review.
	* All project plans must be broken into tasks of no longer than 2 weeks.
	* An updated project plan must be submitted to management every 2 weeks.
	* Task completion is reported on a 0% or 100% done, never 90%.
	* Key parts of the system must have multiple resources familiar with the code.
	* There is a single individual responsible for scope change sign off.
	* Teams must demonstrate the software to management every two months, even if the early demos are boring UML diagrams.
	* All teams must report status to the project manager daily, either through a written report or verbally.
	* Projects that must produce documentation must have a business analyst skilled in writing.

Don't argue about the quality of your horse. Instead focus on setting up
the obstacle course in a way will appeal to management, and yet be easy for
you to clear most of the obstacles.

-- JamesGoebel

----

I like this concept a lot. It appeals to the scientist in me. Who cares how it works as long as it works? A lot of the problem of AdoptingXp is communicating the need for it (see FirstCreateTheMailbox).