- 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
Controlling Risk with XP
By now you should have a definite sense that software development is a risky business, surrounded by uncertainty and change. There are however, some common risks with software development that we can highlight:
Schedule slips—As the work progress it becomes clear that the delivery date is unreachable.
Project cancelled—This is more of a problem when the project size is larger. The customer has been spending huge amounts of money for no perceived business value and they finally pull the plug.
No business acceptance—The system was developed far from the end users and failed to work the way they wanted. The cost or pain of changing the business was too high.
Technical complexity—The tools or platforms chosen are untried and prove too difficult to integrate.
Defect rates high—The quality of the system is shown to be very low, defects are either overlooked or not tracked. When in the hands of the user the system is buggy and defect-ridden. Litigation, rework on commercial impacts are the result.
XP addresses these risks head on by building quality into the software and delivering working software in very small release cycles. Before we tackle our risks, let's review an example of how not to run a software development project.
INCIS: A Case Study of a Software Disaster
In 1994 the New Zealand Police awarded a tender to IBM for the development and delivery of its Integrated National Computerized Information System (INCIS). INCIS was slated to be the first law enforcement information management system in the world to link all aspects of police work at a national level. Five years and $67.5 million later, the project had been scrapped, $15 million over budget and with little, if any, real result. As you'd expect with a disaster of this scale, there was no single root problem. There were some obvious contributing factors:
Complexity—The project was both technically and operationally extremely complex. The level of this complexity was greatly underestimated. This risk was never highlighted or dealt with.
Technical problems—Initially IBM developed their client machines under OS/2; in 1996 they switched to Windows NT at an estimated rework cost of $3.5 million.
Unreasonable deadlines—Deadlines were not based on real estimates of time to complete; politics and marketing set impossible dates that were never met.
Overly optimistic, blinded management—Any issues raised by development staff were typically squashed under the "think positive" regime.
Big Bang approach—Almost all the work had to be completed before the users saw the system. The idea was to replace the old system with a single cut-over. A pilot was run for part of the system, but the results were ignored.
Silver bullet syndrome—Politicians and management placed their faith in technology and tools such as high-level computer languages to overcome obstacles. Due to the length of the project some of these technologies, such as OS/2, became obsolete.
Waterfall approach—The functional specification ran to more than 4,000 pages and had more than 900 variations over the lifetime of the project. It wasn't until the users actually saw the system that they understood what those 4,000 pages spelled out. Naturally, numerous changes were requested late in development, and with the Waterfall approach, this was expensive.
What can you learn from this software disaster? Software development needs to be done in a dynamic, change-friendly environment, and the software itself is the best form of specification. The project managers on the INCIS project made the mistake of confusing documentation with communication.
NOTE
For the official report into this software disaster see http://www.justice.govt.nz/pubs/reports/2000/incis_rpt/schedules/schedule_6.html.
Averting Disaster with XP
You now know the all-to-common risks associated with software development, and you've learned how one project (INCIS) failed because of some of them—namely, Waterfall development, unreasonable deadlines, single release approach, and complexities inherent in the technology. XP has direct ways of mitigating and overcoming these risks. Table 3.2 lists our risks and explains how XP deals with them.
Table 3.2 How XP Mitigates Risk
|
Risk |
Mitigation |
|
Schedule slips |
XP has very short release cycles; any slippage or change is very small. The highest business value features are delivered first and the customer can actually see the software (not merely documentation about the system). |
|
Project cancelled |
In an XP project, since the most important work is done up-front, if the project is cancelled, the XP team/company at least achieved some functionality. This is unlike most software projects, where teams spend the first six months in planning, and if its cancelled, the company is left with nothing to show for it. The XP approach reduces budgetary risk. |
|
No business acceptance |
The customer is part of the development team on a full-time basis. They select the functionality being delivered and can guide as necessary. There is no need to create buy-in because they developed the solution with the rest of the team. |
|
Technical complexity |
The XP practice of continuous integration means that the team is at ease with integrating the complete system, and there is no "big bang" before delivery. The value of simplicity drives code quality through practices such as code standards, pair programming, collective ownership, and refactoring. |
|
Defect rates high |
The use of automated testing and test-first programming establishes low defect counts as a way of life. Issues with functional defects and cosmetic changes are uncovered early by the on-site customer. |
Yes, software development is risky, but with XP we have a structured environment where we can expose and deal with issues before we have another project disaster on our hands.