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.
For me however, although I have used XP as a way of looking at other development processes, XP is not the only game in town. There are lots of different ways of obtaining similar results. Some useful candidates include
There are many other lightweight processes, but this is a reasonable starting point for questioning whether eXtreme Programming is for everyone.
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.
The things that we need to protect when we choose a way of playing the software development game are
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.
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.
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.
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 Programmers my 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.
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.
Agile Software Development: The Business of Innovation
(C) 2000 Software Craftsmanship Inc., all rights reserved.