Extreme Programming Perspectives

The story begins at a small software development company, whose cash flow problems had just brought on a company restructuring and a quest for venture capital. Over their two-year history, the company had struggled with limited market share and had acquired a mind-set of saying "yes" to every customer request. This kept them afloat, barely, but the resulting urgent time frames and unmanaged "featuritis" had damaged the original product design and quality. In 1999, the company hired a new VP of engineering, who championed the need for change and created a protected environment where the development team would have the opportunity to experiment with new methods.

When Kay joined the company shortly thereafter, her first concern was that Ron was the sole survivor of the previous development team the only one who knew anything about the code. Pressed by the need to understand the code quickly, she encouraged Ron to adopt pair programming, which she'd read about on Ward Cunningham's Wiki, as part of that strange "extreme" programming method.Ron and Kay were both somewhat skeptical but didn't see any other way to handle the situation.^[1]

^[1] .Ward Cunningham's Wiki is part of the Portland Pattern Repository, published by Cunningham & Cunningham, Inc. It is the first WikiWikiWeb and is located at http://c2.com/cgi/wiki.

Pair programming actually seemed to work.

They were able to come to solutions much more quickly together than they could individually. The code remained clean and consistent. When bugs slipped through and were discovered by customers, the bugs were usually in code that hadn't been pair programmed.

Based on this initial success with pair programming, they began to consider implementing other XP ideas. They were uncomfortable about the absence of testing on the project. They'd read about unit testing on the Wiki, and although they had never done it themselves or known anyone who had (surely it was too difficult and time-consuming a technique for use on products that have to be developed rapidly), they thought they could give it a try.

Their first attempts at unit testing failed abysmally. They hoped that Extreme Programming Explained [Beck2000] could help them when it came out that fall. Reading the book helped them understand that the XP principles supported each other, but it got them no nearer to applying unit testing to their project.

The breakthrough insight came when Kay attended Object Mentor's XP Immersion course.^[2] She watched James Grenning and Michael Feathers demonstrate refactoring and unit testing on a small program. Then she got to participate for a week on a mock XP project team, coached by Ron Jeffries, pairing and getting a feel for JUnit and test-first programming.

^[2] .XP Immersion is a registered trademark of Object Mentor, Inc. To find out more about XP Immersion, go to http://www.objectmentor.com.

Back at work, with this improved understanding, she quickly got VBUnit working and began practicing test-first programming. Kay and Ron soon discovered that having the test cases in place increased their confidence. They began to see the value of the immediate feedback, helping them focus on only one failure at a time and minimizing the tendency to get lost in multiple distractions. The tests did not seem to be slowing them down. They were learning the truth of Kent Beck's statement: "The mentality of sufficiency … creates its own efficiencies, just as the mentality of scarcity creates its own waste" [Beck2000].

Now it was time to put XP to the test. New programmers were joining the company, some of them quite opposed to the experimental ideas Ron and Kay were trying. Before they went any further, Kay and Ron asked for a separate team to be created that included those favorable or at least neutral to the XP ideas, and found a customer (the third author of this chapter, Dan).

The team had a mixed level of knowledge about and buy-in to XP, but at least no one was openly opposed to XP. Kay set the following policies for the project.

• All checked-in code will be either pair programmed or code reviewed.

• All code changes in the business objects layer will be supported by unit tests.

• A clean compile and clean run of the entire unit test suite must be obtained before checking in code.

• Attend iteration planning meetings every two weeks and stand-up meetings daily.

• At iteration planning, sign up for the same amount of work you completed last iteration.

• The customer chooses which stories are available for sign-up, with the amount of work not to exceed the combined amount the team completed last iteration.

• Only work on functionality required for stories you are currently signed up for.

• Should a story remain uncompleted at the end of the iteration, you may not sign up for the same story you had in the previous iteration (no second chance).

• Team members will not be asked to work more than 40 hours per week.

This was a limited version of XP, but most people in the engineering department perceived it as pretty radical.

The iterations began.

Dan, previously the company's director of client services, had spent a lot of time with our customers but wasn't sure how his new role as product manager would work out. As he began to work within the role of XP customer, he appreciated the structure the process provided and the ability it gave him to more effectively steer the project. He could see how XP encouraged open communication and information sharing among all team members, especially between the product manager and the developers. He appreciated the simplicity and flexibility of using cards and felt they made the planning and scheduling process "more real."

The developers were able to begin coding immediately because Dan worked out the requirements details as we went along. Kay appreciated this, coming from two previous projects where so much time had been spent on requirements and design that there was no time left to code and the projects had therefore been canceled.

As the project progressed, Ron, Dan, and Kay learned how iterations set a rhythm and reduced the constant pressure they'd felt on previous projects. One teammate, who came to this team from a nondevelopment team, commented on how much moving to development reduced his stress.

Because this project was life or death for the company, implementing the 40-hour workweek took courage, but the authors learned that avoiding late-night programming sessions enabled them to be immediately productive the next morning and to spend much less time rewriting mistakes.

As it turned out, the team's initial velocity measurement was quite accurate in predicting how long it would take to complete the project, and they reached code complete precisely when the projections showed. To the authors, this was a great accomplishment, something they had not experienced on other projects. In addition, they were able to estimate for management the time it would take to do certain additional features, which management opted for, and the team was able to add the features in the estimated amount of time.