Distance and eXtreme Programming
School of Informatics, SESI group
University of Wales, Bangor
Dean Street, Bangor, Gwynedd
LL57 1UT, United Kingdom
+44 1248 382686, fax 361429
Extreme Programming (XP) is the lightweight software development process that appears to be a possible solution to the’ method nightmares’ experienced by many organisations. The measurement of success in adopting XP is reported on in a number of publications based on research conducted by the SESI group in collaboration with many .
This position statement includes an experience report on using the practices of XP with a distributed workforce and on measuring the effect of using a tool. A small project was conducted by a development team of 11, 8 in one location, 2 in another and one in another. In addition, all the developers also worked from home.
We wanted to use XP for this project but didn’t necessarily want to change locations of work. A decision was taken to trial a ‘groupware’ system and explore the possibilities of using the tools provided to use XP for a distributed workforce.
The groupware software selected was FirsClass. This was purely a pragmatic choice, due to availability and experience of administering the system by some members of the group.
Communication -A great deal of attention is necessary in providing an XP environment in keeping with the practices to support XP. Key factors in communication are; the use of white boards, positioning and sharing of desk facilities to facilitate pair programmers, ‘stand-up’ meetings, developers ‘buying-in to the concepts of the ‘rules and practices’ of XP, and ‘collective code ownership’. Interviews and questionnaires revealed many areas of concern among developers when attempting to use the FirstClass tool solely for communication. As in other studies a similar percentage (85%) of developers thought that meetings were not well organized and therefore, a similar approach was taken with the tool, concentrating on the development of XP story card practices. Developers were encouraged to agree, and finalise with the client, the task description and duration estimates at timely Planning Game meetings. It was found that the planning game meetings needed to be held in person, and not with the use of technology. Story cards were fully referenced and signed by the accepting developer, thereby becoming the responsibility of the initiating developer until completion. The tool in this case did not prove as useful as was originally envisaged for recording and documentation purposes. The use and placement of White boards is said to be an essential supporting means of good communication in XP practices. The tools’ whiteboard facility was introduced for this project; soon after pair programming practices gained momentum. The pair programming was conducted with the pairs being in the same physical location for this project. Future work will concentrate on selecting more specific software development groupware products to attempt ‘remote’ pair programming. At one point, the decision was taken to ‘enter’ the story cards into the tools whiteboard facility in prioritised order with adjacent notes written on the board. This proved very effective, as copies could be taken of the cards, without physically removing them (a problem with physical whiteboards).
Stand-up meetings promote communication throughout the team. An attempt was made to hold a virtual stand-up meeting with the tool, however a decision was taken to trial this element of distance working for another project with a more specific tool (or a customised FirstClass) with video conferencing facilities.
Other practices, such as Simple Design, Tests, Refactoring and Collective Code Ownership have all been effectively supported using the tool. Currently, a review is taking place to measure the effectiveness of using a tool by applying qualitative research methods. The aim was not of appropriateness of this particular tool, but use of tools in general to support the process. The jury is still out.