Introducing XP Turns Waterfall Project Around

1. would no longer be allowed, and they were effectively insulated from new change requests until the system was thoroughly cleaned up. Team leads in turn got the commitments from individual team members, on the daily basis.
2. Each day is a project. In the morning standup meeting, tasks for the day were defined and agreed to by the team members. At the evening standup meeting, the results were also reported personally by each team member. Not only were the tasks shared, they were also written down on a dozen flipchart sheets and posted on the walls at the beginning of each iteration. As developers completed their tasks, they would walk up to the chart and cross off their tasks. This cemented the teams and restored the feeling in everyone that what they did mattered, and that they were actually getting something done. Everyone was accountable every day, and there was great energy in the teams. (In fact, the charts were especially difficult to get some people to do. In some cases, the company's EVP had to personally oversee planning games and morning standup meetings to make sure people actually wrote tasks down on charts and posted them on the walls.)
3. Granular planning and estimates on the level of hours. Every morning, individual granular tasks were estimated (in hours) and committed to by engineers. A review followed every evening, so estimates were corrected and re-negotiated within the team almost in real time. This practice dramatically improved quality of estimates, within days of being first introduced.
4. Refactoring. Most iterations of most teams were focused on fixing certain defects. Sometimes engineers were able to trace a certain group of bugs to a particular code fragment. Then, at the planning game, instead of deciding to simply go ahead and fix those defects one by one, the team would decide to refactor that piece of code and eliminate the root cause of the problem. As a result, we saw better code structure, better stability, and better performance (with occasional performance boosts of one or even two orders of magnitude).
5. Pair programming. This was the practice that, while recommended by the management, was met with particular skepticism and resistance. However, eventually the infectious enthusiasm of the "XP mentors" convinced some people to try it. Immediately, it was clear that productivity did not really decrease as the "non-believers" had feared (of course, the XP folks knew it wouldn't). At the same time, the quality improved dramatically. The other benefits noted by developers were mutual education and joint code ownership. A number of experienced engineers ended up using pair programming for more complex tasks, e.g. refactoring.
6. Open communication. XP-style communication eliminated a lot of waste and created a great atmosphere conducive to creative and productive work. The mood clearly changed from "we're working hard but it is all in vain anyway so leave us alone" to "if you know how to do things better, just tell us."

The results were, to put it simply, unbelievable. The metrics chart (see Figure 1) shows the dramatic decline in the amount of active defects starting in the beginning of December 2004 (precisely when the XP practices were first introduced). The quality and performance metrics charts were posted on the wall of the project room daily, and this chart has since been framed and placed on the wall in the CEO's office as testament to the power of agility.

Figure 1: Active defects over time

The team initially resisted XP simply because it was new and because for most people these practices seemed quite radical.