What Are XP Projects Scared Of?

Extreme Programming was created to address project risks, but project risks are the symptom, not the disease of software development. Pete McBreen explains the real two-headed beast that makes XP an effective solution.

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.