In praise of XP: why software projects failMost large-scale software projects fail.1, 2 Failures range from the worst-case scenario of projects that are not completed, to projects that are over budget or that fall short of expected goals and objectives. The larger the project, the more likely it is to go belly up, and this often leads to a costly washout for an organization. The recent abandonment of the $100 million F.B.I. Case File system is an example of a project that never produced a useable software system.3
New methods of developing software have been created that address this global problem. Extreme Programming (commonly known as XP) can effectively solve many of the major issues that lead to project complications. XP is a software development practice--some would say a philosophy--that evolved from processes created by developers of the object-oriented programming language Smalltalk in the mid 1980s. With the publication of Extreme Programming Explained, XP gained attention in the software development world, although it's still not widely used within the conservative corporate IT community.4
Even though each less-than-successful project has its own unique causes of failure, we've pinpointed five of the primary factors that underlie most problems, and how XP helps address each of these issues:
• Poor communication
• Incomplete requirements and specifications
• Scope issues
• Inadequate testing
Unclear, inadequate, or inconsistent communication among stakeholders is one of the main reasons why projects fail. Standard development methods usually don't define how all project participants will share information in an ongoing and meaningful way. Business users, technical management, outsourced services providers, and individual programmers are often isolated from one another and therefore do not communicate with each other.
In traditional development projects, the customer's only close involvement in the project is during the requirements and deliverables phases. Such "waterfall" projects begin with the creation of a requirements document that serves as a perpetual and mostly static roadmap. The project moves forward in sequential waves, from design through coding and testing. These waves are often the work of different groups of developers. Within waves, most work is done by individuals working in relative isolation, who post their work to a project manager who then handles the exchange of information among project members.
XP views communication and collaboration as essential keys to the software-development process. The customer is included in the project team and is an important part of the ongoing development cycle. By creating "user stories" that describe specific features the system should support, and by evaluating and approving each component as it is developed, the customer becomes an integral and driving force through the entire life of the project. Programmers benefit from direct access to the customer and are able to create better systems because they understand why the features are important and exactly how they should be implemented. During the programming process programmers work in pairs as a close-knit team. Having brief and relevant daily and weekly meetings ensures a constant flow of communication.
Traditional "waterfall" development begins with a comprehensive requirements document. This often massive guideline is designed to provide the blueprint for the entire project. The problem is that in every project that lasts more than a couple of weeks, specifications will unavoidably change over time. Business requirements change. New aspects of the project come to light. What seemed workable on paper proves untenable in implementation. Despite the almost universal need for changes in requirements and specifications over the course of a project, traditional procedures do a very poor job in systematically integrating such changes.
The XP method solves this problem through an iterative approach to development. Instead of sequential development, teams using XP work through a project by implementing the most important features first and breaking the features down into useful functions that can be created within a week or two. Each component is designed to meet a specific individual requirement, based on user stories created by the customer immediately before the development iteration commences. If requirements change down the road, it's a simple matter to change whatever individual components are affected, provided that the twin practices of continuous refactoring and elimination of code duplication are both followed. Therefore, the development of each feature is as close as possible to the creation of the requirements of that feature by the customer, as opposed to traditional development, where work on specific functionality may not commence for many months after the requirements document has been created.
One of the more common problems in software projects is "scope creep," which can cause discrepancies in cost and delivery time. Scope creep is not a surprising phenomenon since you'd need a crystal ball to anticipate all the changes that can occur in a large-scale software development project with a lifespan of months or years. It's been said before that when estimating large projects, you can be either lucky or wrong. Unfortunately, most estimates aren't very lucky.
Rather than solve the "problem" of constantly changing scope, XP embraces it. XP was intended to be used in projects where requirements are likely to change. By taking advantage of a customer-centric iterative model, XP keeps commitments focused on short-term deliverables that can be accomplished on time and on budget in most cases. Instead of a long marathon, development is divided into a series of shorter sprints, or iterations. Each iteration is focused on a mutually agreed-upon number of user stories, which are created, tested, and approved by the customer before moving on to the next. This system makes it nearly impossible for projects to go very far off-track, since the customer and the development team continually evaluate the work and make sure that it's consistent with the needs of the customer as they evolve over time. Scope is strictly frozen, but only for very short periods of time. The customer is welcome to ask for a feature in one iteration and then completely change his mind in the next, as long as the "story" for the current iteration remains the same. This is generally acceptable to even the most demanding customers, since they know that they have complete control over what gets developed when.
Traditional development methods save testing for the final phase of a project. This schedule is problematic because issues with core architecture may not be exposed until a project is almost completed. At that time, correcting such fundamental problems can be costly or may even require an almost total revamping of the code base. Another factor that adds to testing issues in traditional development is that testing is often under-funded and constrained by time. By the end of the project developers are usually under tremendous pressure to deliver the completed software on time, so the first roll-out of the new software is often an unofficial beta test.
XP provides an elegant solution by turning the tables and creating a test for each component as the first step of each programming task. Creating the test before undertaking the coding ensures that the developer understands exactly what each component should accomplish and provides a verifiable benchmark to ensure that they meet the customer's need. Problems are found quickly and can be remedied at relatively low cost.
Large projects using traditional development methods often fall apart during the integration process. It's common for different teams of programmers, who may be geographically dispersed, to work in relative isolation on individual parts of the project for long stretches of time. As they finish their work, they typically turn over the code to the project manager who then assigns it to a new team who attempts to integrate the disparate components and make them all work together. Since there had been no consistent communication between the teams during the development process, significant problems often arise at this stage as different interpretations of the requirements or their implementation becomes apparent.
XP mitigates this issue in a number of ways. First, ongoing meetings and a collaborative ethic ensure that the entire team has an understanding of the entire project. Instead of working on their own task in isolation, each participant is aware of and involved in the discussions about the entire project. This communication makes it much less likely that bad assumptions about other project components will result in compatibility issues. XP also uses a "round robin" approach to integration. Every project team integrates its own code into the project. As teams check the code in and out, there is a continual process of integration and ongoing problem solving. Further, since iterations are only a week or two in length, integration happens by necessity at the end of each iteration, which greatly decreases the complexity and risk of the process. This system not only lessens the likelihood of integration problems, but also makes solving any problems that arise less problematic.
XP success story
We've found the XP method relatively easy to implement internally. Although clients must be educated initially, we've found that it greatly increases customer satisfaction and provides them with software that closely meets their needs, even if they change during the course of a project.
It's a relatively simple matter to test the XP waters on a small scale. A good starting place would be to read Extreme Programming Explained by Kent Black and Cynthia Andres. The Agile Alliance (www.agilealliance.org) is also a great resource. It is a nonprofit organization that supports individuals and organizations who use agile approaches to develop software. Many organizations, including ours, offer training in XP and can mentor internal developers to create self-sustaining in-house expertise.
Nate McKie is the CTO Asynchrony Solutions, an IT services firm. Nate has over 15 years of industry experience in corporate development and project management.
David Elfanbaum is vice president of marketing and business development at Asynchrony Solutions. David's career has focused on helping small businesses market themselves effectively.
You can reach the authors through firstname.lastname@example.org.
1. The Standish Group International, Inc. The CHAOS Report (1994), 1995. www.standishgroup.com/sample_research/chaos_1994_1.php.
2. Schwartz, Ephraim.'"IT Myth 5: Most IT projects fail; Reality: It all depends on how you define failure" InfoWorld, August 13, 2004. www.infoworld.com/article/04/08/13/33FEmyth5_1.html?s.
3. Goldstein, Harry. "Who Killed the Virtual Case File?" IEEE Spectrum: Vol. 42, Issue 9, Sept 2005; Online at www.spectrum.ieee.org/sep05/1455.
4. Beck, Kent. Extreme Programming Explained. Reading, MA: Addison-Wesley, 1999.
The XP concept is extremely good, except the organic growth of project (breaking project into small customer-viewable features) is not mappable to a good architecture design. Writing whole project in small features means a constantly changing architecture (since the whole requirements were never addressed initially, the architecture was never made to handle those.) Once we start implementing features, we find the architecture inadequate and so end up modifying it. But modifying something in architecture means older portion can break and need to be fixed and re-tested. If a tested architecture is already in place, then XP is best way to go. If not, then we need to first build an architecture based on the basic customer requirements and make sure customer is aware of limitations of the architecture. Then go about making each feature based on XP model. Where the requirements are too vast to build an architecture initially, a prototype modelling is the best approach to start. After prototyping, go with incremental model, but define an increment, wherein ( and only where) the team will do architectural changes.
In short, while XP is powerful, there is strength in older models that XP lacks. Only a combination of these can help in successful projects.
"Traditional development methods save testing for the final phase of the project." Not the traditional methods I am familiar with! Professional software development standards, going back to the 1980s, promote a V model testing scheme, where independent Formal Qualification Testing begins and ends the software development lifecycle. If by turning-the-tables, as this article suggests, XP promotes unit test over FQT, then decades of established wisdom have been abandoned here.
But what if the project is time constrained? Simply relax the formality and thus effort in the time consuming unit review and testing phase - take the risk that coding problems will be detected in integration testing and FQT.
Professional (traditional?)software development standards likewise promote the analysis, specification and management of user/customer requirements over the production of code. Why? As many studies over decades have shown, and this article alludes to, poor requirements are the serial killers of software development.
Finally, I concur with Jeseem of Canada--if XP abandons or demotes architectural design then beware, it can only be successful on small, non-complex developments.
- Martin Allen
The article is a good introduction; however, there are a couple of things that could be brought out.
An important aspect of XP is pair programming. It's worth discussing as it is one of the harder adjustments for the programmers and a key efficiency concern for managers.
It's important to stress that iterative coding and testing are no substitute for good module level design. I hope the books will emphasise this, but programmers generally find time spent iterating (and getting quick results) more fun than detailed design. Good supervision is essential to make sure the design is right.
The difficulties of embedded systems development (especially debug) put a premium on problem avoidance through good design, rather than simple functionality. I believe that for XP to become useful in embedded development achieving the balance between good design and rapid development is critical.
- Darren Hutchinson
"Most large-scale software projects fail... Extreme Programming (commonly known as XP) can effectively solve many of the major issues that lead to project complications."
One might infer from this article that XP is suitable for large-scale software projects. However, even Kent Beck does not claim this (from a review of Extreme Programming Explained): "The focussing of the whole code development around pair programming, unit testing and continuous system integration is fascinating. This helps give XP its great flexibility, but as [Kent] Beck admits, continuous integration probably limits the development team size to at most 10 in practice." -- www-users.cs.york.ac.uk/~susan/bib/nf/b/beck.htm.
- Kevin R. Priest