The New Methodology

　　XP (Extreme Programming)

　　Of all the agile methodologies, this is the one that has got the most attention. Partly this is because of the remarkable ability of the leaders of XP, in particular Kent Beck, to get attention. It's also because of the ability of Kent Beck to attract people to the approach, and to take a leading role in it. In some ways, however, the popularity of XP has become a problem, as it has rather crowded out the other methodologies and their valuable ideas.

　　The roots of XP lie in the Smalltalk community, and in particular the close collaboration of Kent Beck and Ward Cunningham in the late 1980's. Both of them refined their practices on numerous projects during the early 90's, extending their ideas of a software development approach that was both adaptive and people-oriented.

　　The crucial step from informal practice to a methodology occurred in the spring of 1996. Kent was asked to review the progress of the C3 payroll project for Chrysler. The project was being carried out in Smalltalk by a contracting company, and was in trouble. Due to the low quality of the code base, Kent recommended throwing out the entire code base and starting from scratch. The project then restarted under his leadership and since became the early flagship and training ground for XP.

　　The first phase of C3 was very successful and went live in early 1997. The project continued since and ran into difficulties later, which resulted in the canceling of further development in 1999. (which if nothing else proves that XP is no guarantee of success.)

　　XP begins with four values: Communication, Feedback, Simplicity, and Courage. It then builds up to a dozen practices which XP projects should follow. Many of these practices are old, tried and tested techniques, yet often forgotten by many, including most planned processes. As well as resurrecting these techniques, XP weaves them into a synergistic whole where each one is reinforced by the others.

　　One of the most striking, as well as initially appealing to me, is its strong emphasis on testing. While all processes mention testing, most do so with a pretty low emphasis. However XP puts testing at the foundation of development, with every programmer writing tests as they write their production code. The tests are integrated into a continuous integration and build process which yields a highly stable platform for future development.

　　On this platform XP builds an evolutionary design process that relies on refactoring a simple base system with every iteration. All design is centered around the current iteration with no design done for anticipated future needs. The result is a design process that is disciplined, yet startling, combining discipline with adaptivity in a way that arguably makes it the most well developed of all the adaptive methodologies.

　　XP has developed a wide leadership, many of them springing from the seminal C3 project. As a result there's a lot of sources for more information. Kent Beck wrote Extreme Programming Explained the key manifesto of XP, which explains the rationale behind the methodology and enough of an explanation of it to tell folks if they are interested in pursuing it further. In the last couple of years there's been an epidemic of brightly colored XP books, most of which are pretty similar in that they describe the whole process from the point of view of various early adopters.

　　As well as books, there are a fair number of web resources. To find a more structured approach to XP, it's best to start with two sites from C3 alumni: Ron Jeffries's xProgramming.com and Don Wells's extremeProgramming.org. Much of the early advocacy and development of the XP ideas occurred on Ward Cunningham's wiki web collaborative writing environment. The wiki remains a fascinating place to discover, although its rambling nature does lead you into being sucked in. There is an active, and often interesting xp discussion egroup. One of the more interesting "outside" views of XP is that of Mark Paulk, who is one of the leaders of the CMM community - his paper looks at XP from a CMM perspective.

　　Cockburn's Crystal Family

　　Alistair Cockburn has been working on methodology ever since he was tasked by IBM to write about methodology in the early 90's. His approach is unlike most methodologists, however. Instead of building on solely personal experience to build a theory of how things should be done, he supplements his direct experience with actively seeking to interview projects to see how they work. Furthermore he isn't afraid to alter his views based on his discoveries: all of which make him my favorite methodologist.

　　His book, Surviving Object-Oriented Projects, was his first piece of advice on running projects, and remains my number one book recommendation for running iterative projects. More recently Alistair has written an overview book on agile software development that looks at the underlying principles of these kinds of methodologies.

　　Since that book he's explored agile methods further, coming up with the Crystal family of methodologies. It's a family because he believes that different kinds of projects require different kinds of methodologies. He looks into this variation along two axes: the number of people in the project, and the consequences of errors. Each methodology fits into a different part of the grid, so a 40 person project that can lose discretionary money has a different methodology than a six person life-critical project.

　　The Crystals share a human orientation with XP, but this people-centeredness is done in a different way. Alistair considers that people find it hard to follow a disciplined process, thus rather than follow XP's high discipline, Alistair explores the least disciplined methodology that could still succeed, consciously trading off productivity for ease of execution. He thus considers that although Crystal is less productive than XP, more people will be able to follow it.

　　Alistair also puts a lot of weight in end of iteration reviews, thus encouraging the process to be self-improving. His assertion is that iterative development is there to find problems early, and then to enable people to correct them. This places more emphasis on people monitoring their process and tuning it as they develop.