TABLE OF CONTENTS We have already said that XP is not a design method. Indeed, all it actually is in any formal sense is a set of four values that have motivated twelve practises. Some of these practises are more clearly oriented towards a process than others. For example, the planning game practise, as we will see, has a lot to say about itself. Other practises, such as the 40-hour week are rather more like guidelines, than a process. That is, you either over work your developers doing 60 80 hours a week or you don't. There is not a lot to say about how you limit the number of hours worked to 40 (exception management buy in and developer acceptance).
Therefore, at times, XP can seem deceptively simple. When you follow the set of twelve XP practises, you're away. That is, if you follow these twelve practises (which seem fairly straightforward) you will be doing XP. However, this is a deceptively simple approach. I have witnessed projects that claimed to be doing things the XP way and at a first glance they were certainly paying lip service to the XP practises. But, they had failed to really comprehend what XP was all about or truly understand how to implement XP within a software development project.
We will return later in this book to the subject of how you can introduce XP into a larger project methodology for larger applications, or how you can apply a software development process to an XP...
