Results from the Experience

The following is a commentary on XP practices and a brief summary of results taken from a selection of XP practices investigated at ST.

Pair Programming

Beck justifies the use of pair programming and why it works [Beck2000; Beck+2000]. Williams maintains that two programmers working together generate an increased volume of superior code, compared with the same two programmers working separately [Williams+2000A]. XP takes advantage of the benefits of pair programming reported for some time [Cockburn+2000; Williams+2000B].

Management at ST discussed the feasibility of implementing pairing with their development team, who unanimously agreed to buy in to the practice. The first questionnaire showed that some of the team were unhappy with pairing; 28% of developers preferred to work independently, 57% didn't think they could work with everyone, and 57% stated that pair programmers should spend, on average, 50% of their time alone. XP practices recommend that no more than 25% of a conditional 40-hour week be paired. Two developers summed up the team's early attitude to pair programming.

I feel that pair programming can be very taxing at times, although I can see the benefits of doing it some of the time.

Not everyone makes an ideal pair. It only really works if the pair is reasonably evenly matched. If one person is quiet and doesn't contribute, their presence is wasted. Also, if a person is really disorganized and doesn't work in a cooperative way, the frustration can [disturb] the other participant!

In fact, developers estimated that they spent approximately 30% of their time pairing, with partner changes occurring only on task completion, often spanning several days. Changes in pair partners were only infrequently agreed on and then mostly established in an ad hoc manner.

This activity did not conform to the frequent partner swapping and partner mixing recommended by XP. Pairing practices matured with the introduction of a team "coach" and later a "tracker" [Beck2000]. Maintenance tasks were another problem, which routinely disrupted pairing. Here, control was reviewed and tasks better ordered to minimize this problem. In time, the impact of pairing activity on developers may be seen by comparing the data returned from the periodic questionnaire reviews and in the timeliness and quality of code released. Only from the results of broader and longer-term evaluations of this kind will the benefits of this evolving practice be understood.

Planning Games

Jeffries et al. detail each step in the planning game scenario [Jeffries+2000]. The "customer" duly chooses between having (a) more stories, requiring more time, and (b) a shorter release, with less scope. Customers are not permitted to estimate story or task duration in XP, and developers are not permitted to choose story and task priority. When a story is too complex or uncertain to estimate, a "spike" is created. Spike solutions are found by writing sample code that breaks down the problem into simple stories that are then easy to estimate, and they provide answers to complex and risky stories.

Planning games were introduced at ST soon after pairing practices were established. As an application service provider, which provides applications to a large number of clients, ST produced enhancements incrementally every two to four weeks in response to feedback from customers, sales representatives, marketing executives, and corporate management. Because of the number and distribution of project stakeholders, a true "customer on-site" model was not practical, and ST evolved a "customer proxy" model.

Commenting on the proxy model, the developer manager stated:

The inclusion of a representative from customer services has proven to be hugely beneficial, providing immediate feedback of the system's successes and failures on a day-to-day basis.

Customers were given an on-site "proxy" who represented their interests during the planning game and during development. The customer proxy understood the customers' needs in detail and always acted in the best interests of the customers. A typical planning game involved several customer proxies and internal representatives from the sales, marketing, and operations departments. The stories to be implemented in subsequent releases were selected by consensus among stakeholders, during the planning game, to determine the order in which stories maximized business value. ST managers reported that they were pleased with the progress, development, and results of planning games. Reaching a consensus among interested parties often involved considerable discussion and was facilitated by the XP developer manager. However, the XP manager also played the role of "corporate management proxy" by communicating corporate strategy into the planning and by interpreting the story priorities in the context of corporate strategy. Qualitative research methods in this case, the researcher immersed within the project team played a useful role in abstracting and collating information.

Problem requirements routinely arose, and the team quickly adopted the spike mechanism for dealing with complex stories. Their method was to create spike solutions by logging a spike as a fully referenced story to quickly attack a problem. This effectively reduced a complex, inestimable story to a simple and easily understood group of stories. Results were very effective; spike solutions proved easy to develop, and consequently estimates for completion, derived at planning games, proved consistently accurate. In the early stages of implementation, it was common practice to combine the essential elements of both iteration and release planning games in one meeting. This practice worked for ST in the context of their limited, earlier projects. In addition, as confidence improved, planning games quickly matured into separate full-blown release and iteration planning games, and larger projects were soon brought online to adopt this and other XP practices.

Communication

A great deal of attention is necessary in providing an XP environment in keeping with the practices to support XP [Beck2000]. Key factors in communication are the use of whiteboards; positioning and sharing of desk facilities to smooth the progress of pair programming; stand-up meetings to broadcast knowledge and negotiate support; collective code ownership; and finally the principle of buying in to the concepts, rules, and practices of XP.

Interviews and questionnaires revealed many areas of concern among developers. For example, with respect to meetings, when developers were asked if meetings were well organized, with results agreed on, recorded, and effectively communicated to everyone, 86% of developers disagreed and added comments such as these.

Agreements at meetings are not set in concrete.

Confidence is lost with meeting procedures when agreed action or tasks are later allowed to be interpreted freely by different parties.

This type of qualitative feedback, provided from periodic reports, alerted management to address these concerns by concentrating their efforts on improving XP's planning game and story card practices. In part this was addressed by encouraging developers to agree on, and finalize with the client, the task description and duration estimates at timely planning game meetings. In addition, story cards were fully referenced and signed by the accepting developer, thereby becoming the responsibility of the initiating developer until completion. Only the "responsible" signatory of the story card was authorized to amend it. However, not all the issues have been fully addressed, and some problems with meeting practices remain at the time of writing.

The use and placement of whiteboards is said to be an essential supporting means of good communication in XP practices [Beck2000]. Mobile whiteboards were introduced by ST soon after pair programming practices gained momentum, and were used to record the story details agreed on at planning game meetings. At one point, story cards were physically stuck to the boards in prioritized order, with adjacent notes written on the board. This proved unpopular and developed into cards being retained but not stuck on the whiteboard. Tasks were written on the boards. Referenced tasks contained ownership, estimation, iteration, and priority, which were displayed in column format. On completion, the owner added the actual task duration. The information served to improve personal proficiency in estimation and in providing feedback toward establishing project velocity data for future planning games.

Stand-up meetings promote communication throughout the team. ST introduced this practice from day one. At ten o'clock every morning, a meeting allowed everyone to briefly state (standing promotes brevity) their work for the day and discuss problems arising from the previous day's activity. Anyone was free to comment, offer advice, or volunteer cooperation. The benefits of adopting stand-up meetings were far-reaching and seen by developers and management as an effective way to broadcast activities, share knowledge, and encourage collaboration among team members and management. ST meetings tended to degrade when reports migrated to topics of yesterday's activity rather than those planned for the day. This activity persists and may remain or need to be resolved and modified as their particular brand of XP develops.

Simple Design

Beck summarizes simple design with "Say everything once and only once" [Beck2000]. However, one developer revealed a common concern, which was recorded at a periodic interview.

Sometimes, it is a bit too simplistic, and issues seem to be avoided.

XP states that it is important to produce a simple system quickly and that small releases are necessary to gain feedback from the client. ST didn't see themselves in a position to exhaustively implement the simple-design practice early in their XP implementation program. XP was introduced to maintain and enhance an existing system, which did not have automated acceptance or unit tests. This severely hampered the refactoring of legacy code in situ, and only when most of the functionality was migrated into XP clean code, did serious refactoring become possible.

Testing

Acceptance tests are written in XP before the main code and give an early and clear understanding of what the program must do. This provides a more realistic scenario, as opposed to "after-the-code testing," which, unfortunately and for many reasons, neatly matches completed code. Time is saved both at the start of coding and again at the end of development. At ST, latent resistance to early testing became evident when the perceived closeness of a deadline loomed. Testing is perhaps the hardest practice to implement fully and requires above-average commitment from developers. An early questionnaire revealed that 71% of developers regarded unit testing practices in general to be "very poor." The developer manager commented on the early introduction of unit testing, saying:

If you already have a large, complex system, it is difficult to determine to what extent testing infrastructure is to be retrospectively applied. This is the most difficult aspect in our experience. Starting from scratch, it's much easier to make stories and code testable.

With experience and the results of qualitative investigation, ST concluded that applying unit tests and acceptance tests to existing legacy code is counterproductive in the long term.

ST adopted the following additional policy with respect to testing.

• Start from a clean slate whenever a portion of the legacy system needs modifying.

• Write acceptance tests up front.

• Construct new applications with unit tests.

• Use small portions of legacy code in a new implementation only when necessary and appropriate.

Refactoring

Martin Fowler describes refactoring as "the process of improving the code's structure while preserving its function" [Fowler1999]. The use and reuse of old code is deemed costly. Developers are often afraid they might unwittingly break the software. XP advocates that refactoring throughout the project life cycle saves time and improves quality. Refactoring reinforces simplicity by its action in keeping code clean and reducing complexity. ST had not developed refactoring activities in line with XP at that time. Many developers expressed concerns with refactoring that are more commonly reported by traditional companies.

With more people, we could spend more time refactoring and improving the quality of our existing code base.

The questionnaire revealed that 45% of developers considered refactoring sporadic or very poor. Many poorly developed practices blame resources as the key factor in restricting progress. In this instance, management has committed to facilitating change and improving their refactoring practices; future studies will monitor change and progress.

Collective Code Ownership

Kent Beck describes this concept as "Every programmer improves any code anywhere in the system at any time if they see the opportunity" [Beck2000; Beck+2000]. Collective code ownership is purported to prevent complex code from entering the system, and developed from the practice that anyone can look at code and simplify it. Although sometimes contentious, test procedures in XP are there to support collective code ownership and facilitate the prevention of poor code entering the system. Collective code ownership has the additional benefit of spreading knowledge of the system around the team. ST experienced growing pains in developing collective code ownership, as revealed by the comments of two developers.

I have conflicting interests in collective code ownership. I think it is very good when it works, but there are times when some code I have written seems to just get worse when others have been working on it.

I like the idea of collective code ownership, but in practice I feel that I own, … am responsible for, some bits of code.

From the familiar traditional perspective of individual-ownership, it will be pivotal in the development of XP to record attitude changes during the transition to XP practices, when acceptance (or rejection) develops among staff and managers. Changing to collective-code-ownership may prove difficult where pride of work is inherently important to job satisfaction, and may need to be balanced by something equally important, perhaps in the form of stronger team awareness, belonging, and commitment. Collecting and reporting such qualitative factors, supports the evolution of this practice.

The Metaphor

A metaphor in XP is a simple shared story to encompass and explain what the application is "like," communicating a mental image so that everyone involved can grasp the essence of the project in a term universally understood. This may seem to be a relatively easy or lightweight activity to adopt. However, the value of this practice was not immediately evident to developers at ST, who experienced early difficulties in developing and applying suitable metaphors. Metaphor usage was consequently, and reluctantly, abandoned for future consideration.