We are using eXtreme programming since 1999 in a number of development projects. On the one hand at the University for teaching purposes and at the other hand inside the company for professional software development projects. We have just finished a project where we developed a set of tools for another software company within 11 weeks, with 7-8 developers and unclear and changing requirements. We managed to finish it successfully with about 1000 integrations, 1-2 releases per week (1-2 releases per day at the peek), using pair-programming and most of the other XP values and techniques. As you can see we did a lot extreme programming and gained experience in realizing XP for real world problems. These days we run about 5 XP projects within the company, all of them with a different team size and different application domains in different settings. We distilled a number of advises, tricks and best practices we would like to share and discuss. Some of them are described very briefly here.
The XP process is fragile. As we moved to XP with our framework development project, the longest running project inside the company, we tried to establish continuous integration for the framework development process. In the beginning, we failed to use the one physical integration machine and the XP process broke. Then we reified the continuous integration technique with a nice artifact, the JWAM IntegrationServer, which provides an extremely easy and fast way to use continuous integration (extending a version management system with additional rules and conventions would have been the alternative). We have been using our tool very successfully since one and a half year and thus found out that providing good artifacts (in addition to the XP values) is useful to stabilize the process.
The Customer Role:
It is our thesis that XP, in its current form, fails to address the actual situation at the clientís organization in a suitable way. The main stakeholder, i.e. the users and their management, are merged into a single role: the customer. This one role cannot address the different forces in a development project. The users of the future system know their application domain in terms of tasks and concepts, but they rarely have an idea of what can be implemented using current technologies. Moreover, it is often misleading to view the users of the future system as the goal donor. They are unfamiliar with the strategic and business goals related to a project and, more important, they do not control the money. Therefore we make a distinction between the role of the user and the role of the client. The users have all the domain knowledge and therefore are the primary source for the application requirements. The client sets the goals of the development project from a business point of view. The client will only pay for a development project if these goals are met to a certain degree.
The Story Cards Approach in the "Exploration Phase":
We found the Story Cards/Task Cards approach to work very well when the basic structure of the software under construction was already present and the continuous, iterative process was running smoothly. On the other hand, when starting from scratch, we found Story Cards to not work so well (unless the customers has a rather concrete idea of the software to be build, which we encountered rarely). In the absence of the ideal customer (see our remarks on the customer role above), we come to rely on techniques like interviews and the writing of use cases and glossaries to get a grasp of the current work situation, the processes and the domain language. We apply the short releases rule to these documents to get feedback from the users/clients and start an iterative, participative development that guides us to the construction of prototypes. These help us to find a base where we can start using the Story Cards/Task Cards approach of XPís Planning Game.
What can you do if you have to work with programmers that refuse to program in pairs? Is "kicking them out" the only possibility? We are going to share some experiences and thoughts on that.