'''''XpPitfalls'''''

	* '''Problem:''' People on your team (customers, managers, developers) '''say''' they are willing to do XP, but secretly don't want to do it. XP is too much work to expect people to do if they don't really want to do it.

Solution: If you are not in charge: run away! You're never going to convince
them.

Solution: If you are really, truly in charge: fill your team with people who
really do want to do XP. (Even if you are in charge, you probably can't
force people to do XP right.)

Solution: enforce DailyBuilds and FrequentReleases first. These apply pressure to other activities, extreming them.


	* '''Problem:''' You think you understand XP, but you don't.

Solution: Hire an outside consultant to visit your team from time to time
and tell you how you are really doing. Since you can't know that you don't
understand XP, this should be a requirement of all XP projects.


	* '''Problem:''' You over-apply the implementation of your previous XP process to your next project

Solution: Remember the principles and values of XP -- in particular ''Simplicity.'' Always start simply. Don't confuse a 
local solution with a general practice. Keep your last n project's practice implementation in your tool box until you need them. Never assume you know the best way to do something. Treat each way as '''a''' way, not '''the''' way.
----
'''Problem: I know I don't understand XP'''

I know I don't fully understand XP, but the XP literature seems to be focussed more on catch phrases rather than on the details of running an XP project.  I don't have the budget to hire an outside consultant for my team, nor believe that I could justify this expense to my customer (the customer is not really concerned with how we develop the software, but is concerned with the cost).  I have flexibility in scheduling, but I cannot afford to waste a lot of time stumbling through XP and not providing some sort of deliverables.

'''Problem: I am in charge, but do not want to micro-manage'''

XP requires a lot of discipline and I do not have the time and temperament to continuously monitor my developers.  Most developers a very comfortable with just writing some code (they know it is right) and having an extended "testing" phase while I have to justify schedule slips.