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).