Results of the Experience

Customers in a traditional development project count on schedule slippage. One of the Company's customers was surprised and pleased to learn that actual time came in at 120 hours for her project, with all stories finished ahead of schedule, instead of the estimated 200 hours. The customer, though, had slipped her own target date, and her inability to take advantage of the new available product contributed to the Company's financial struggles.

Executives enjoyed a new level of control over the end product of developers. Harder to accept was that "You still can't have it all at once." It was challenging to allow developers to set their own time estimates instead of operating to business agendas not based on the capacity of the development team.

The product management process was realigned to enable the product managers to drive the development process and to own the features under development.

The Company, at the time of writing, had passed its twentieth iteration of XP. In a space of five months, the organization leaped from Level 1 in the CMM to Level 4, in which:

An organization-wide software process database is used to collect and analyze the data available from the projects' defined software processes … the process is measured and operates within measurable limits. This level of process capability allows an organization to predict trends in process and product quality within the quantitative bounds of these limits. [Zubrow+1994]

Goals 1, 2, and 3 had been achieved, but goal 4 had not.

Goal 1: Making the Development Team More Responsive

The team changed priorities with very little notice and provided customers with what they requested.

The team demonstrated results and provided product for customers ahead of schedule.

Goal 2: Increasing Speed and Reducing the Error Rate

One team, at the time of writing, had created over 1,000 unit tests. A release required running all 1,000 tests, plus user acceptance tests. The increased degree of control of testing at all levels increased the degree of confidence in the product.

The quality of developer output increased significantly for those teams writing unit tests and programming in pairs. This is measured by the number of user acceptance tests that failed after release to QA, which was close to zero for those teams.

Goal 3: Improving Development Cycle Flow

Customer ability to determine development priorities increased the customers' confidence in their development unit.

Prioritization, at a corporate overall strategic level, a project level, or a story level, became easier as skill at estimation improved.

Creation of smaller development teams, with each team responsible for a specific product, increased velocity and job satisfaction.

The level of communication among customers and developers increased greatly. Before XP, communication between customers and developers was actively discouraged, exacerbated by environmental barriers of separate rooms and floors. With XP, communication between customers and developers became constant.

Goal 4: Improving the Company's Financial Situation

The Company did not achieve the improved financial position it sought. Factors other than XP, both internal and external, were more influential on the Company. The Company experienced several layoffs during the time period described, and its survival is not ensured at the time of writing.

Other Observations

Extreme flexibility places heavier responsibility on executives to produce adequate strategic plans. Responding to sudden changes is part of XP, but requiring extreme changes for each iteration is usually not sound business practice.

The lack of emphasis on documentation within XP does not take into account end-user needs for documentation, including user guides, integration kits, references texts, and fact sheets.