Page 298 -

the course of the project. In addition to the user stories, they are responsible for negotiat-
ing which user stories are included in each release, giving feedback on the results of each
iteration and, most importantly, filling in the details that are missing from the user stories.
Testing in XP consists of unit tests and acceptance tests. All code must have unit tests, and
all unit tests must pass before the code can be released. When a bug is found in produc-
tion, an additional unit test must be written to guard against it in the future. When soft-
ware is delivered, the customer is responsible for running acceptance tests to verify that the
user stories are all implemented properly. The customer is responsible for verifying that
the acceptance tests are correct—meaning that the unit tests truly verify that the work has
been done—and for reviewing the results of the acceptance tests to determine whether
the software is ready for release.
Many programmers have turned their struggling development teams around using XP.
One of its biggest advantages is that it does not require widespread organizational change,
which means that it can be implemented by a small group of programmers without getting
managers involved. For a team that does not have any project planning or requirements
gathering, working in an XP environment will be an enormous relief. XP is an effective
way to promote good social and organizational change by putting good development and
project management practices in place. It’s no wonder that there are a growing number of
professionals who have come to depend on XP for all of their work.
One common misunderstanding is that XP is not a disciplined or well-defined process, and
that XP and the CMM and ISO 9000 are all somehow mutually exclusive. In fact, XP
projects follow a very specific set of rules and practices. It is possible for a good team that
has fully implemented XP to pass a CMM or ISO 9000 assessment.

On reason XP is effective is that it addresses one of the most common problems in soft-
ware development: the hands-off customer. Just as a hands-off client can cause serious
problems in an outsourced project (see Chapter 11), serious project problems can happen
when a stakeholder does not act as if he has a real stake in the software. It is very easy for
a software project to go off track, and it needs constant direction to keep the scope of the
project current with the organization’s needs. XP provides an effective solution to this
problem by making the stakeholders a part of the development team and requiring them

to be involved in the day-to-day work of the project.
There are, however, some important drawbacks to XP. It is not clear that XP can be
extended to large teams. Some experts feel that XP is difficult to implement with teams
that are larger than about 12 people. (There is some research in this area, and a few
researchers have reported success on large teams using a modified version of XP.) Another
drawback is that it only works on software projects that can be delivered incrementally, or
do not have human users. The original C3 project at Chrysler was a payroll system; it’s not
clear that XP would work for a different team at Chrysler developing a fuel injection sys-
tem or anti-lock brake system.

290 CHAPTER TWELVE