What Are XP Projects Scared Of?
- XP Was Created to Address Project Risks
- But Project Risks Are Symptoms, Not the Disease
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
A popular, successful software development methodology will upset a lot of people.
Extreme Programming is an interesting approach because it evolved out of successful software development practices in the Smalltalk world. As such, it pays much more attention than any of the other approaches to what developers do on a project. It also is mainly focused on fears that developers have about projects as opposed to fears that the organization has about projects.
One way of characterizing XP would be to say that it was created by developers to allow them to do what they want to do, while reassuring the organization that the project will deliver successfully. Although this could be seen as an uncharitable interpretation of XP, it turns out that the fears that developers have and the fears an organization has about a project are reasonably aligned.
XP Was Created to Address Project Risks
As Kent Beck states in the opening sentence of Extreme Programming Explained, "The basic problem of software development is risk." [Beck, 2000, p. 3] The examples of risk are instructive:
- Schedule slips
- Project canceled
- System goes sour
- Defect rate
- Business misunderstood
- Business changes
- False feature rich
- Staff turnover
Each of these risks is grounded in developer fears.
Developers really fear schedule slips because they are high profile and are never forgotten by the organization. Plus, developers feel really stupid having to explain last-minute slips. Canceled projects are a real drag because they, too, are never forgotten by the organization. Developers also fear cancelation because it creates a gap in the resume, and because developers never want to be part of the conversation that starts, "I see you worked on the project that flushed $10 million."
Similarly, developers are scared of projects when the system goes sour and/or has a high defect rate. Both mean lots of stress and long hours, marathon "debugging" sessions stepping through incomprehensible code, and having to explain to the organization why major portions of the new system are going to have to be rewritten.
Misunderstanding the business is a real fear for developers because it is a great way to get into a really awkward situation. Not only do the developers have to explain why the mistake occurred, but they also have to go back and fix it.
Business changes are terrifying because there is nothing worse for a development team than to be told that the software they have lavished most of their waking hours on is irrelevant.
False feature rich is something that developers get scared of only as they gain experience. Early on in their careers, developers just love to add cool stuff into applications, but eventually every developer ends up in a situation where he has to explain to a project lead why he wasted time on the cool feature when there was more important stuff to work on.
Staff turnover itself is not really something that developers fear, but they are scared of being on a really great project team and then finding that conditions deteriorate to the point that they start looking for work elsewhere.