Extreme Programming
11 July 2013
Extreme Programming (XP) is a software development methodology developed primarily by Kent Beck. XP was one of the first agile methods, indeed XP was the dominant agile method in the late 90s and early 00s before Scrum became dominant as the noughties passed. Many people (including myself) consider XP to be the primary catalyst that got attention to agile methods, and superior to Scrum as a base for starting out in agile development.
Jim Shore's description of Agile Software Development is heavily based on the principles of Extreme Programming, and is my first choice as a guide to learning the XP approach.
Kent developed XP over the course of his consulting to Smalltalk projects in the late 80s and early 90s. The full set of practices that came to be known as XP were first used together in the C3 project (where I worked with Kent and learned about it). The name “Extreme Programming” came later as the approach was described, first informally on the WikiWikiWeb and then later in a series of books. Various teams took the description in the WikiWikiWeb and implemented XP themselves, thus replicating the methodology and showing it could be used outside its original home.
Kent describes XP by a progression of ideas from broad and abstract values through principles, to concrete practices - a progression that I find useful to apply in many other contexts. It popularized many practices that have since been widely used in software development, including: continuous integration, refactoring, TestDrivenDevelopment, and agile planning. I particularly like its combination of technical and management practices, which make it a good fit for reaching the delivering zone of agile fluency 1.
1: a contrast to Scrum which intentionally only includes management practices, and is thus vulnerable to becoming FlaccidScrum
The “white book” is the definitive description of Extreme Programming and deserves a spot on any programmer's reading list.
Although, like most XPers, I don’t think it’s terribly useful to judge a team on whether they are doing XP or not; I would say that most Thoughtworks projects operate in a style that is primarily influenced by XP.
Further Reading
The definitive description of Extreme Programming is Kent’s white book. (Beware that many of the early practitioners of XP learned the approach using the first edition, and there’s quite a few differences.)
Although the White Book is the best definition of XP, these days I recommend James Shore’s The Art of Agile Development as a guide to learning the XP approach. Although Shore casts his net wider than Kent’s work on XP, his book is firmly grounded on XP’s key features.
Notes
1: a contrast to Scrum which intentionally only includes management practices, and is thus vulnerable to becoming FlaccidScrum