Introducing XP Turns Waterfall Project Around


Conventional wisdom is that complex projects involving large groups of engineers can not benefit from the application of Agile techniques. Certain Agile practices, when properly used, can benefit even relatively large development projects with large teams. What's even more interesting, these practices can be introduced in "mid-stream" with little preparation to large teams of "old school" developers. These developers may initially resist the methodology, but the Agile practices still win people over and bring tremendous results in productivity, product quality, and team morale in a very short period of time.  

Introducing XP
XP was first introduced in StarSoft in 2002, after our CEO read Kent Beck's "XP Explained: Embrace Change." Later that year, StartSoft won its first Agile customer, a world leading chip manufacturer. The customer picked us specifically because its internal development organization was based around the practice of XP. Since then, StarSoft has successfully delivered over 60 Agile projects. Today, over four years later, we can say that XP has become very much a part of the company's culture. According to our COO whose office is in the hallway that leads to the cafeteria, he can tell when an XP team is going to lunch as opposed to one of the "waterfall" teams: they even walk faster because they feel they have no time to waste!  Engineers either like or hate XP; however, conversions are entirely possible even for the most die-hard "old school" engineers. We have {sidebar id=1} found that for most young developers, the clarity, focus, and high productivity yielded by XP are infectious and people become ardent promoters of the methodology within the organization. No engineer who has tried XP has ever wanted to go back to "the old ways."

The Labka II Project
StarSoft introduced XP to a large-scale software development project for Computer Sciences Corporation (CSC) in Scandinavia, yielding some interesting results. A large and complex system called Labka II that had been in development for three years was about to go into production. Labka II is a medical laboratory information and production planning system supporting requisition and analysis of clinical chemical samples, blood cell analysis, and the like. The system communicates with a large number of advanced lab instruments. Labka II controls test requests, definition of work, schedules, collecting and processing test responses, validation and approval, reporting, data exchange, quality assurance, production statistics, and extract for invoicing. The underlying technology is based on BEA WebLogic, Oracle, AIX, MS SQL and Windows. Labka II can service a large hospital or a network of hospitals in a region or a county. The StarSoft project team size reached up to 80 people at peak times. The system contains over one million LOC, 700+ DB tables, and 40MB+ of source code.

The StarSoft team was having trouble getting performance and quality under control. Labka II is replacing the legacy Labka system and detailed specifications were developed and handed down to the team up front. Inevitably, CSC and its client (one of the largest Scandinavian hospital systems) introduced numerous changes in the course of the project to take advantage of the new technologies and include advanced functionality in the new version of the system. The problem was that we were not very wise in how we processed the changes to the scope: we simply accepted the requests without communicating back to the client the impact that the requests were going to have on the project's complexity and timeline. We were just saying "yes" to everything and hoping it would somehow work. At the same time, our internal project organization was largely inefficient and was not coping with the amount of work (see more on that later). Eventually, we had to learn from our mistakes the hard way.

After several months were spent polishing the system, it became increasingly clear that some of the algorithms (suboptimal "patchwork" code written by separate people at different times due to poor processing of the influx of change requests over a long period) created acute performance problems and the number of fixed defects was constantly lagging behind the number of new defects found. Both CSC and its client were unhappy because the



About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.