Results from the Experience

Events after completion of this project became rather surreal. At the shipping party, the team that actually worked on the project received no credit for shipping successfully. A new manager was hired to take care of this team. When layoffs came shortly thereafter, this team was the one that was let go, while the team that had missed all their deadlines but had worked more overtime was preserved.

Clearly, there was a difference in perception. The authors' perception was that their team had delivered superior performance, based on the fact that they accomplished the project according to the schedule they had gotten management's agreement on, and had team members who were happy and excited to work on the next project. The company's perception was that the team had delivered inferior performance that they could have gotten the product out sooner if they had put more effort into it.

The differences in perception became more clear after the authors interviewed the other team members and management. The interview responses were surprising at first. Some of the developers said this project was the best work experience they had ever had; others felt the project was average at best. Some of the evidence the authors thought indicated success, such as the 40-hour week and delivering on schedule according to a measured velocity, were even considered negative factors by management and one of the developers, who thought the team showed a lack of commitment for not working overtime or faster than the estimates.

What most people agreed on was that the ruthless prioritization performed by the product manager helped the team stay focused on the most valuable functionality. The planning meetings always seemed to go well, and everyone got to feel the iteration rhythm. Even those generally opposed to XP did appreciate the predictability, sense of completion, and increased feedback that came from the short iterations.

In the end, the authors learned an important lesson: They learned that XP is best understood when actually tried.

The authors themselves didn't understand XP or fully believe it would be beneficial until they tried the practices. Even then, it took experiencing the practices with mentors at XP Immersion before the authors were really able to make progress on building new understandings.

The authors and the other developers who consistently tried the XP practices became convinced of their benefits and felt the practices were improving the software delivery process. Those who avoided the XP practices were never convinced of their value and never became comfortable with the practices, most notably test-first programming and pair programming.

Table 35.1 summarizes some of the differing viewpoints that were discovered in the retrospective interviews.

The authors also learned that it is hard to sell XP to management. Management did not participate in the team experience and thus saw even fewer advantages to the XP practices than the team members did, especially when it came to project scheduling. They did see that the team was doing something different. Management is usually under pressure, and this case was no exception. Under pressure, and looking from the outside, they do not usually perceive different ideas as good.

Table 35.1. Differing Viewpoints on XP Practices

Responses from Those Who Tried More of the XP Practices	Responses from Those Who Tried Fewer XP Practices
Writing tests saves debugging time and makes it possible to clean up the code.	Writing tests is too much work for too little benefit.
Pair programming results in better solutions sooner and promotes good discipline and effective teaming.	Pair programming is a waste of time except for teaching someone new about the code.
Adjusting the workload to match last iteration's velocity makes the schedule predictable.	Signing up for only as much as you did last time encourages slacking.
The 40-hour workweek results in better quality by removing pressure.	The 40-hour workweek demonstrates a lack of commitment.