Is XP for Everyone?

Introduction

eXtreme Programming is a new development
process that is starting to dominate the conversation about minimal methodologies.
Although most of the practices in XP are not new in and of themselves, the combination
of practices has turned out to have very beneficial, synergistic effects.

There are many other lightweight processes, but this is a reasonable starting
point for questioning whether eXtreme Programming is for everyone.

Looking at Software Development as a cooperative game

The idea of software development as a cooperative game was originally expressed
in the Humans and
Technology's Manifesto for software development (Link Rotted)

"Software development is a cooperative game, in which people use markers
and props to inform, remind and inspire themselves and each other in getting
to the next move in the game. The endpoint of the game is an operating software
system; the residue of the game is a set of markers to inform and assist the
players of the next game. The next game is the alteration or replacement of
the system, or creation of a neighboring system."

For a better understanding of this use if the word game, read Finite
and Infinite Games by James P. Carse, which talks about the distinction
between Games that we play until someone wins - finite, and games we
play so that we can continue playing - infinite.

There are different ways to play the software development game. The markers
and props that XP uses are not the same markers and props that the Unified Process
uses. Each process has it's own set of markers and props, and although the OMG
has tried to standardize the notation on the Unified
Modeling Language, each process uses the UML in a slightly different way.
The markers that we leave behind are different. XP values the source code as
the most important marker, other approaches value documented source (as in Javadoc
html files that come with most Java libraries), or CASE tool models showing
traceability back to the original requirements.

One of my main reasons for remaining on the sideline of the XP game is that
Use Cases are one of my favorite props for
the requirements gathering activities. So much so that I even teach Alistair
Cockburn's course on Writing Effective
Use Cases. XP's User Stories could easily be as effective as Use
Cases, but Use Cases seem to work better as a marker when the Customer is
not available to answer questions.

Choose a process that allows the game to continue

The things that we need to protect when we choose a way of playing the software
development game are

We ship the software meeting all stakeholders needs and budget

We want to work together the same way on another project

If we manage to do these two things, we have succeeded in perpetuating our
infinite game. If we miss either of these two, game over. So we
need to be careful to ensure the process we pick matches the culture and problem
domain so that we can successfully deliver.

Talking about Methodologies

We need a way to talk about methodologies without getting sucked into any specific
position. XP and the Unified Process so dominate the conversation that it is
hard to talk about using some practices that have been popularized by XP without
being seen as promoting (or incorrectly using) XP. Hence I have to be careful
when I talk about Applying the Lessons
of eXtreme Programming, to make clear that we are using ideas that XP has
made popular (like Refactoring and
XP style unit testing with JUnit)
to think about the process we are currently using.

Examine the consequences of the Methodology

What is the methodology going to feel like on a moment by moment, day by day
basis? Does the rhythm feel natural to the team? Are all the activities and
deliverables understandable by the team? At some point in a project, using the
process is going to seem harder than working off process (But it's only
a one line change, why do we have to do all that extra work?). What
mechanisms exist to ensure that we stay on-process? XP uses pair programming
for all production code and a Coach who carries a Rolled Up Newspaper for the
purposes of administering a Zen Slap to people who work off-process ;-) Other
processes use a deliverable based review, paying attention to the quality of
each deliverable rather than the process used to create the deliverable.

Who benefits from the methodology and who pays for those benefits? In many
processes, the person who benefits from an activity is not the person who has
to perform the activity. In those cases, the outcome is very dependent on the
culture of the organization. Staying on process can be hard is people are complaining
that all this make-work is slowing us down. Talking in terms of
props and markers that we need to move the game forward can be useful in this
context, but only if there is sufficient understanding of all of the roles involved
in successfully delivering great software systems.

How much will each person have to change their behavior? Depending on where
an organization is starting from, what people do might not change very much,
but the necessary change can be drastic. My favorite example of this is when
adopting Use Cases for requirements capture. Using Alistair
Cockburn's Writing Effective Use Cases style, before you can say a Use Case
is complete, two important checks have to be made, the business has to say how
they will know that the developers have delivered the functionality, and developers
have to feel comfortable that they can deliver it. One drastic change is that
systems analysts are required to think about how
to acceptance test every use case, and to do this while they are capturing
the requirements.

Few developers realize how profoundly their day changes with XP

Although there is a lot of developer push for XP, my experience has been that
few developers appreciate the distance between their current practices and the
XP Practices. Especially when a developer espouses not commenting code,
working without CASE tools, delivering incrementally and intertwining designing
and coding, the discipline of adopting XP comes as a real shock. XP values clear,
well factored code with intention revealing names that conforms to the teams
coding standard and XP practitioners will keep Refactoring until comments
are no longer needed. This is a long way from a Three
Star Programmersmy code is so good it doesn't need comments
viewpoint. An example of Three Star code is :-

if (x=**y[i]){ ... }

This kind of code would not survive on an XP project, it would get refactored,
and the perpetrator would get to wear the Propellor
Beanie for digging too far into their bag of tricks.

So should we apologize for not using XP?

No way!

When the conditions suit XP, I can see that using XP would be really great
(as well as resume enhancing). Under different conditions, although you might
be able to bend XP to fit, there are other process choices available.

Just as people prefer different sports, different people gravitate towards
different processes (ways of playing the game). When there is a match between
your preferred style of play and the project you are working on, great things
can happen. When there is a mismatch, interesting things happen (as in the curse
May you live in interesting times).

We should however be very careful not to fall into the IncompleteXP or Pretty
Adventuresome Programming trap that says we are Almost Doing XP, since the
synergistic effects that give the real benefits of XP seem to only be available
when you follow all of the XP practices. So you should apologize if you are
attempting IncompleteXP, but that is the only time you should ever apologize
for not doing XP.