Overcoming Software Development Problems with XP
- Uncovering Software Development Problems
- Controlling Risk with XP
- Improving Quality with XP
- Managing Change with XP
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Before we go more in depth with XP it is helpful to have a solid understanding of what key problems XP overcomes. Some of these were hinted at during Hour 1, "Setting the XP Landscape." In this hour we'll uncover the major software development problems and see how XP resolves them. By the end of the hour you will have learned
-
How you can control your project's outcome with XP
-
What the key risks are with software development and how XP mitigates them
-
How XP projects produce quality software products
-
How XP embraces change during development
Uncovering Software Development Problems
In this section we will uncover some of the most common problems with software development. Then, we will isolate four variables that you can use to control the outcome of your project. Before I explain what these are and how XP manages projects differently, let's dig a little deeper into why software projects go bad.
The Software Development Crisis
In Hour 1 we discovered how software engineering was born in the late 1960s as a response to the rising level of project failures. Something had to be done and rigorous control appeared to be the answer. Thirty years later software development still struggles with bad press from what seems an endless list of project failures and cost overruns. A 1995 research article from KPMG reported on the causes and effects of project failure. The top reasons for software project failures were
Project objectives not fully specified
Bad planning and estimating
Technology new to the organization
Inadequate or no project management methodology
Insufficient senior staff on the team
Poor performance by suppliers of hardware/software
The Denver International Airport (DIA) Baggage Handling System is one of the most publicized and dramatic examples of a software runaway. The images of luggage littered throughout the baggage claim area, dismembered, and spat out by the hugely complex automated system, became headline news during 1994–95. The idea was to take an existing, simple baggage-handling system that worked well and scale-up to a more complex, integrated system. After stumbling through delay after delay, the airport finally opened on February 28, 1995, with more than $300 million spent on the automated baggage system for United Airlines. The vision to develop a completely integrated system, serving all airlines had failed. Shifting goals, technical challenges, politics, and personnel change had all combined to derail the project.
Software runaway is a project that goes out of control primarily because of the difficulty of building the software needed by the system.
Your software development projects might not approach the complexity of the DIA baggage handling system, but you can learn lessons from such spectacular failures. Some industry pundits claim we are in the midst of a software "crisis" where the chances of completing a successful project are extremely poor.
NOTE
The software runaway article is available from: "Runaway Projects—Causes and Effects," Software World (UK), Vol.26, No.3, 1995, by Andy Cole, KPMG.
To summarize, your project is liable to drift into runaway if you lack a development strategy that is highly flexible, open, and scaleable. XP attacks this risk at the root by embracing change and accepting it as the norm. The practices support dynamic development that weeds out defects in quality as they occur.
The Death March
Software runaway projects are typically started with a good chance of success, but the wheels fall off during development. Increasingly developers are being dragged, tricked, or happen into a new style of software project: the death march. Edward Yourdon devotes an entire book to this subject (Death March—The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects, 1997), for now we'll gain an understanding of how XP can aid you in not just surviving but overcoming the death march.
Death march is a project that after objective analysis has greater than 50% likelihood of failure.
Death march projects start with little chance of success; they are doomed to fail. Apple spent years developing what was to be its new operating system, code-named "Pink," all the while continuing to treat it as a two-year endeavor. Expectations were not adjusted when it became clear development could never be completed within a two-year time frame. Pink was eventually dissolved with seven years worth of effort wasted. Whether this project was a runaway or a death march is immaterial; it was a failure. Yourdon lists some of the typical reasons for death march in his book:
Politics—Internal or personal factors result in impossible constraints being established ("the project must be completed by 1 May"). These constrains are either never questioned or issues are swept under the carpet with the smokescreen of "its just politics."
Naive promises—Senior management makes promises to customers or marketing without checking with the development team.
Naive optimism—Developers with little experience or maturity, underestimate the effort involved. When committed they lack the confidence to retract their estimates.
The "Marine Corps" mentality—Developers understand the impossibility of the task ahead, which becomes some kind of weird challenge. This do-or-die mentality is fueled by a lethal mix of inexperienced team members, weak project management, and a general gung-ho attitude.
How can XP help with a death march? One obvious way is the XP practice that mandates a 40-hour work week. XP allows change to the scope of the project, but not the cost, time, or quality.
The Four Control Variables in Your Project
There are four variables that you can control in your software project: time, cost, quality, and scope, as shown in Figure 3.1.
){kind=link}
Figure 3.1 The four variables of development.
What then are the impacts of controlling your project using these variables? The customer chooses three of the four and leaves you to manage the fourth. Which is the best control variable? Table 3.1 lists our variables and the side effects of controlling each.
Table 3.1 The Four Control Variables and Their Effect
|
Variable |
Effect |
|
Time |
Too little time will certainly impede the quality of the product because there's not enough time to listen to customers, code, or test. On the other hand, extending the timeframe (not common) might not yield the answer you expected. The role of the development team is to implement changes as quickly as possible so that the customer can give feedback. Quality might be improved by lengthened timelines, but, as we will discuss later in this chapter, there is more to quality than bugs. |
|
Cost |
Can throwing money and resources at the project save you from disaster? Adding more resources to a project that is already late will only succeed in making it later. The customer needs to fund development to the estimated level, but should not expect that pouring money into a project in strife will cover issues. |
|
Quality |
The worst of our control variables! Reducing quality can appear to quicken development time, but in the end we've only succeeded in moving testing into the hands of our end users. |
|
Scope |
The standard procedure with software development is to only begin work after the scope has been agreed to and signed off. Tying down requirements and scope is an uphill battle in this model. Customers want to make sure they throw in everything they think they want and might want in the future. |
How do we overcome software development issues and challenges with XP? We allow the scope of development to change, fix the other variables, and develop using the 12 XP practices.
NOTE
Allowing scope to change does not mean an unlimited-length project! The key word is change. If the customer adds a new feature request they will have to remove something of equivalent size. This is quite different from scope creep where the customer continually adds requests that the team never planned for.