Introducing Agile Development (XP) into a Corporate Webmaster Environment – An Experience Report

Author(s): Ganis, M., Leip, D., Grossman, F., Bergin, J.
Venue: Agile Conference, 2005. Proceedings.
Date: 24-29 July 2005

Type of Experiement: Other
Sample Size: 8
Class/Experience Level: Professional


Agile Conference, 2005. Proceedings. Page(s):145 – 152. Digital Object Identifier 10.1109/ADC.2005.31.

Introducing Agile Development (XP) into a Corporate Webmaster Environment – An Experience Report recounts the experiences of a group of 8 programmers working for an internal IBM organization when they moved from a traditional waterfall-driven software engineering model to extreme programming. The team knew nothing of extreme programming, but was tasked to work on the IBM corporate portal, the root of a large web presence that directs users to more and more specific sites within IBM. The portal receives great amounts of traffic, typically ranging from 40,000 to 50,000 hits per minute and peaking at about 60,000 hits per minute on an average week.

The customer’s goal was to have the team develop a set of modules for the portal homepage to support a concept called “task based navigation”. As development proceeded, the scope expanded to include a new feature called the Query Manager that would enable the customer to manage and fine tune navigation queries. The portal needed to be accessible to four countries, each with its own set of localized/translated pages and individual queries. Overall, the system was comprised of roughly 300,000 files (including html, css, graphics, etc).

Before 1994, the IMB corporate web portal had been developed using a typical waterfall methodology. However, deadlines slipped too often because while customers were deciding on requirements, too little work was getting done. Often there was enough knowledge of what was needed to allow programmers to move forward with some design and development, without having to wait for a complete picture to be fully understood. Additional, the concept of having working code at the end of short release cycles was appealing not only to the development organization, but to the customer as well. As such, extreme programming was adopted with open arms.

The team learned the extreme programming practices using “Extreme Construction,” developed by Bergin and Grossman, which teaches the agile values and principles and the basics of extreme programming in a full day. Each of the twelve practices of extreme programming is included in at least skeletal form. The team was not only trained, but the customer as well, which turned out to be critical later in the project, as doing so made communication easier later on.

The team enjoyed great success being able to work in an environment of rapid feedback, and having the customer on site meant that there was constant customer interaction. Even so, one issue the team encountered was when the customer attempted to manage not just the stories for the project, but the resource as well. Although this conflict caused problems at first, it was overcome once the problem was mediated.

The planning games in the beginning suffered from having too many people involved. The customer, along with their staffs, development team, and their management personnel, made for quite large planning meetings, diminishing productivity.

Additionally, paired programming was used successfully, but when two external Java developers were hired on the team out of necessity, tension arose, especially when the new recruits were paired with the original team members. However, as the project progressed and the team began to “gel”, this issue became less of a problem.

Frequent builds were problematic for the team due to lack of experience with code management and lack of a clear understanding of a build process. As the project progressed, builds were being delivered more frequently, but always at predetermined times, as opposed to suggested practice of having builds delivered every night.

Overall, the authors report a highly successful experience with extreme programming. Early customer involvement was absolutely critical to the success of the project, not from a pure requirements perspective, but having the customer understand and be part of the development process. Education of the team, the customer, and those groups outside the immediate team helped increase communication, which then increased productivity. Finally, the authors propose that a clearer architectural model (like a metaphor) that could have been shared with colleagues would have contributed to the project’s success, had there been one.