Industry publications and trade groups are touting the benefits of Extreme Programming (XP), so you may be wondering if it’s time to hop on the bandwagon yourself. Sure, XP is hot, but it’s a major shift in business practice, and it’s not for every development team or corporate culture.

Check out these articles and member comments for an overview of the XP approach and a look inside the experiences of other enterprise developers who have gone “extreme.”

XP vs. “the way that we’ve always done it”
In “Pick up the pace with extreme programming,” contributor Brian Clark outlines the 12 core practices of XP and how the approach differs from traditional development processes. A major shift is increased focus on customer feedback in the development process. In the traditional development methodology, customers or the internal business driver typically gets involved at the beginning and end of the process. Clark warns that excluding the customer from ongoing development touchstones fosters feelings of distrust between programmers and business drivers. If milestones are missed, this distrust can erupt into animosity, with business folks calling developers “overpaid” and “arrogant.” Imagine that.

Let go of my ego
A chief tenet of XP is peer review, which of course has been around for quite some time. Web editor Lamont Adams explores the benefits of informal peer code reviews in two articles. In “The case for informal peer review in a development organization,” Adams argues that just as QA verifies that your application meets business requirements, only another developer can help you tweak code line-by-line.

Before your start forcing your programmers to share a keyboard, read Adams’ “Egoless programming: The path to better code,” in which he spells out his (Almost) Ten Commandments for preventing your code review sessions from turning into free-for-alls as soon as someone’s code is called “inefficient.”

Does XP practice make perfect?
In “Extreme Programming: Do these 12 practices make perfect?” Scott Withrow, a development director, expresses skepticism about XP, saying it may be something of a fad.

In an online discussion, member Evan J. Goff raises some questions about how XP can be used for system design. “I think XP offers some good practices for coders, but I have some concerns when considering XP from a project development process perspective,” Goff writes. He adds that a key barrier may be describing what are inherently technical issues to the nontechnical stakeholders immersed in the XP development process.

Got the XP blues?

Did implementing XP not work for your organization? Send us an e-mail or post a comment below.