system development, the customer. The user. The people who are actually going to be working with the system, living, breathing, eating with it over the next several years. And it really forces the users to be part of the process, through the planning games, through stories. No longer can you have a user say, "I don't have time for that meeting." Users are actually in the same room as the programming team. Users work along with and build the requirements on an iterative basis. You can't escape. And if you don't like your users, you'll learn to like them. If your users don't like you, they'll learn to like you. Because communication's really the fundamental piece of Extreme Programming.
One of the other values is simplicity. And that comes through in refactoring, which is one of the major concepts. Taking a look at small, bite-sized pieces. Now, extreme programming is not for everyone. It is not for the huge, monolithic Department of Defense projects. It is really intended for programming teams of about three to ten people where your requirements are not solid. You're not stuck in a traditional environment. You're really a new type of company, where your system developments can work within some new ideas.
Feedback is also one of the values of XP, and courage. And that's a very interesting thing, because one of the things I've noticed about the XP e-group is that everybody seems to have a sense of humor. And when Kent Beck says that it's a new, fun way of programming, I really believe that. I think that it really brings the fun back into doing some of the programming and some of the development.
Who gets involved in XP? Well, you can't escape. You really have a unified group of programmers working with the managers, working with the customers. And that's an essential part of