Extreme Programming 'Bill of Rights'

Once upon a time when I talked to people about Extreme Programming (XP), it was all new, and I usually needed to start completely from scratch. Those days are over. Now when I ask people at my presentations if they've already heard of XP, a lot of hands go up. From my perspective, this is good, because I'd like more people to be aware of how XP can help them develop software more effectively. But increased awareness is often accompanied by its evil twin—misconceptions.

Software development is not black and white
Whatever other qualities it might have, software development is rarely a land of black and white alternatives. It's a land of enormous variety, populated by people with widely different needs, so it's not surprising that when two people look out over the same part of the landscape, one of them sees beauty and elegance, and the other sees an intellectual desert. XP seems to generate this sort of response, all the way from the name up. After all, why call it “Extreme Programming”? If one more person asks me if XP involves bungee cords or skiing down vertical slopes, my response may cause bodily injury!

I've heard a number of interpretations: One is that the emphasis should actually be on the “programming,” because one of the central notions in XP is that the programming activity is primarily responsible for delivering business value. Another is that “extreme” refers to how often a team follows the individual practices. For example, any team can pair programs some of the time, but an XP team pairs programs all of the time.

Kent Beck, the father of Extreme Programming and one of the founders of the Agile Alliance, says that the term was intended to convey the intensity with which programming can be done. “Extreme Programming is an aware and focused activity—all dials turned to 10—attending to everything you need to attend to and wasting no energy on things that don't matter,” Beck said. Although Beck says it wasn't his intent, my experience is that one of the strengths of the name is that it provokes an emotional response. Jim Highsmith, creator of the Adaptive Software Development methodology and frequent author and commentator on agile software development, echoed this sentiment in Agile Software Development Ecosystems when he reflected, “I don't think many people would get excited about a book on 'Moderate Programming.' New markets, new technologies, new ideas aren't forged from moderation, but from radically different ideas and the courage to challenge the status quo.”

Extreme Programming: Solution or hoax?
Some people behave as if XP is the solution to every software development problem, and some people behave as if it's a hoax, something that isn't appropriate in any software development situation. Of course, the truth is somewhere in between, but if you have a discussion with either the XP or anti-XP zealots, you're likely to walk away with a rather distorted vision of what XP really means.

I don't have the space here to confront all the misconceptions of XP that I encounter, but misconceptions are almost always inconsistent with XP's underlying values. So if you understand the values, misconceptions become easy to spot. XP expresses its values in a variety of ways, including statements of rights for the various participants. Any XP project should be consistent with these rights. Note that specific time frames may vary from project to project.

Customer rights

• The customer has the right to plan on a large scale with costs and options.
• The customer has the right to set development priorities weekly.
• The customer has the right to see progress in the form of a working system at the end of the first week, and to see a little more functionality every week thereafter.
• The customer has the right to updates of the schedule, good or bad, as soon as the information is available.
• The customer has the right to change his/her mind without paying exorbitant costs.

• The programmer has the right to estimate work and have those estimates respected by the rest of the team.
• The programmer has the right to honestly report progress.
• The programmer has the right to produce high-quality work at all times.
• The programmer has the right to know what is most important to work on next.
• The programmer has the right to ask business-oriented questions whenever they arise.

• The manager has the right to an overall estimate of costs and results, recognizing that reality will be different.
• The manager has the right to move people between projects without paying exorbitant costs.
• The manager has the right to monthly updates of progress, and to help the customer set overall priorities.
• The manager has the right to cancel the project and be left with a working system reflecting the investment to date.