Extreme Programming Perspectives

Preparation

The Company hired Object Mentor to provide training and on-site mentoring. The first iteration and release planning games were scheduled for January 2001. The Company had the necessary human resources in-house, consisting of 14 developers, four product managers, and three quality assurance (QA) specialists. The Company created a lab area for pair programming, with walls for posting stories, and a large whiteboard.

Object Mentor coaches spent three days per week at the workplace, providing training, advice, and encouragement. They were heavily involved in guiding employees through the first release and iteration planning sessions. Their time with the Company decreased gradually to two days per week, and by early March 2001, their on-site time ended, although they were available by phone or e-mail as needed. The start and end of the first iteration was timed so that Object Mentor coaches would be on-site on those days.

Product managers, the on-site customers, were to be the connection point to internal and external stakeholders. They would write stories and determine which stories would go in a release, based on the Company priorities.

QA staff would write tests for stories instead of creating tests for already produced code, as they had done previously. QA tests would be available to developers at the beginning of each iteration.

The developers would experience the most upheaval in their day-to-day work. Supervisory developer positions were to be eliminated, although those in the positions were retained, but the perceived demotion engendered resentment toward XP. Developers would work in pairs, lacking the privacy of cubicles. They were expected to write tests before writing code, whereas previously, they wrote few, if any, tests and not until they finished a project.

One staff member would record all stories, tasks, estimates, and who was responsible for each task. She would provide accurate information on velocity for each developer, each story, and each iteration.

Iteration 1

Getting estimates for the first release took a day and a half, with developers forming four groups and each group providing an estimate for every story. The developers did not understand the big business picture the stories represented and became bogged down in issues of business and design.

Customers' early stories lacked sufficient detail to describe the problem clearly and did not always provide a business solution to the problem. Here is an early story.

Suggest using some status indicator for where participants are at in terms of agreeing/modifying/viewing a transaction in the event that other participants (multi-buyer/seller config) are unable or unwilling to acknowledge a transaction (or not even receive e-mail). (Starteam, CR 352)

The product managers prioritized the estimated stories and grouped them into four iterations, making up the first release. Then they obtained task estimates for the stories in the first iteration, a process almost as difficult as the first high-level estimation process. Once the task estimates were done, sign-up followed quickly, and work began on the iteration.

The developers previously had made many business decisions, and this responsibility was taken away from them. Despite their stated desire for better business input, this was a rough transition. Many of them did not like pair programming or test-first design. In time, developers who remained uncomfortable with the process chose to leave the organization. The product managers, on the other hand, welcomed the increased communication and ownership of the business content.

At the end of iteration 1, the actual development time of 335 hours was much lower than the estimate of 598.5 hours. The developers delivered the cleanest code that had yet been tested by QA. The stories that were promised for the iteration were, with one exception, completed. Product managers were confident that the product delivered was what they had requested.

Iteration 2

Suddenly, business priorities changed drastically. All the stories previously scheduled for iterations 2, 3, and 4 were pushed aside as two new projects moved to top priority. The product managers were not prepared for this extreme change, so they had to rush to develop adequate stories and obtain estimates for them. Task estimates were approximately half the time of the original story estimates, so customers did not have sufficient stories prepared to load the iteration, having based their iteration velocity on the original story estimates. Actual times for iteration 2 tasks were still significantly lower than estimated task times: 178 hours actual versus 285.5 hours estimated (see Figure 34.1). Some scrambling ensued during the first week to add more stories to fill up the iteration. However, this experience proved that XP can handle rapid changes in business priorities.

Stand-up meetings settled into a regular routine, although the product managers had to be reminded to include QA in their story-writing activities and, especially, to inform QA of all changes to the story.

The specialization of the development team emerged as a challenge. Because developers signed up for tasks according to their specialties front end (ASP), middleware (Java), or back end (Oracle) work was not evenly distributed. Some developers were overloaded, but others did not have enough to do; yet they resisted working across areas of specialization. It did not make sense for customers to choose their stories based on the availability of developers, so management began discussing alternatives.

Iteration 3

By iteration 3, most team members were more comfortable with the XP process. Iteration planning meetings shrank from one day to two to three hours. Product managers presented a high-level business overview to the development team at the planning meeting, laying the groundwork for stories to fit into a project. Stories were presented for estimation on flip-chart-size Post-it note pads rather than index cards. Story quality improved. Here is an example.

Action when participant clicks "disagree" on escrow instructions:

MUST show up on history log.

Change button text to "disagree/cancel."

Change message at the top of screen to:

"A participant has disagreed with this transaction. This action has closed the transaction." (Starteam, CR 1265)

Because estimates were still not very accurate, product managers routinely prepared more stories than they thought would be needed for the iteration, to ensure it would be filled up immediately. However, product managers had to allocate velocity to competing customer projects that continued to fluctuate in priority from one iteration to another.

Challenges and Changes

By the end of iteration 3, several problems had to be addressed: uneven workloads for developers because of their different roles, lower productivity than needed to achieve company goals because of inaccurate estimating, and continually shifting project priorities. Therefore, management broke the development team into three teams, each one led by a product manager and responsible for a specific project.

Two projects involved creation of a new code base, so those teams were better able to apply XP principles of unit testing than the team working on the legacy code. The team members working on the old code base were selected in part for their resistance to XP. They did not write unit tests and did little pair programming. This team initially appeared to make more rapid progress in stories completed than the other two teams. However, at release time, the advantages of XP became obvious. The XP-resistant team's code required a three-week test/fix/retest cycle before a release to production could be made.

Each team had separate stand-up meetings and separate planning meetings. The planning meetings became much shorter about one hour and more focused. The ability of developers to accurately estimate stories and tasks improved. One team's estimate was 103 hours, compared with an actual time of 72.1 hours, for iteration 10.

There was no longer competition between product managers for developer velocity, because each had their own team. Iterations were changed from two weeks to one week, although after about a month, they returned to two-week iterations because the weekly format took too much planning time.

Documentation

Initially, product managers used index cards, recommended by XP proponents. Because the Company used Starteam 4.2 as its version control and tracking software, stories on cards became CRs (change requests) in Starteam. Product managers eventually reduced use of index cards and focused on CRs. They were easier to track, easier for multiple users to access, easier to modify, and eliminated duplication of effort.

Stories posted in the lab for the developers were written on flip-chart-size Post-it note pads, with CR numbers and a title. Developers added tasks to each CR, their time estimates, and who was responsible for the task. Each task was checked off when finished.

Release notes contained the stories for a given release, but a traditional "feature guide" was created for external use.