Books, Web sites, conferences, and "experts" in Extreme Programming abound these days. The latest StickyMinds RoundTable is devoted to the subject. Agile methods have their critics as well. Read this week's column by Bill Walton for some of his objections to the latest approaches, and see if you agree.
I have some major concerns about eXtreme Programming. XP may be a great way to develop software but, as currently constituted, it's really bad business. XP's fundamental premise that the software will be done when it's done and will cost what it costs is the antithesis of sound business practice. Its insistence that the customer be involved throughout the development process is equally unreasonable. If XP proponents don't successfully address these problems, XP will suffer the same fate as the long list of other iterative practices that preceded it.
To be sure, XP insists on some very good technical practices, among them test-driven development, continuous integration, and the adoption of a single coding standard to be adhered to by all the programmers on a development effort. Other core practices, however, are of questionable merit. In explaining the "Whole Team" practice, for example, Ron Jeffries, one of the founding members of the Agile movement, says on his Web site (XProgramming.com), "The best teams have no specialists, only general contributors with special skills." This seems to me to be good evidence of XP's intent to keep software development in a craftsman stage, in direct opposition to the business objective of seeing it evolve into a more engineering-like discipline.
My primary objection to XP and the other Agile methodologies, however, is the disrespect it shows for management's role in the process. The whole thrust of these methodologies can be summed up with the phrase "you'll just have to trust me." Sorry folks. As we say in Texas, that dog don't hunt. One of the most "in your face" practices is the "one-page requirements document." Someone should let these folks know the Internet bubble burst. The "plan on a napkin" days are over. Really. Another objectionable practice is what they call "the Planning Game." Again, from Jeffries' site, we are told "[t]he emphasis is on steering the project-which is quite straightforward-rather than on exact prediction of what will be needed and how long it will take-which is quite difficult." So XP practitioners aren't interested in working on the hard problems? A new one, to me at least, came out of a session on Agile Testing at the XP/Agile Universe conference. Quoting from the write-up on the ObjectMentor.com Web site, "Use a whiteboard or colored cards instead of a defect tracking system-faster feedback." Feedback to whom? Doesn't management, who's funding this effort, deserve any insight into the process? It seems the Agile movement's position on management's role is "hand over the money and leave us alone." One word comes to my mind: adolescent.
The proponents of XP seem to know full well what the foundation of the problem is: end users cannot easily visualize the solution to their problem. Martin Fowler, another of the Agile movement's founders, says on his Web site ( MartinFowler.com), "Only when you use an early version of some software do you really begin to understand what features are valuable and what parts are not." But do they address this problem? Only insofar as it lets them get on with programming. "We'll just do it in little pieces. That will make it easier for the end user to get what they need. But we can't tell you how many pieces are needed to solve the whole problem. So the end user will just have to stick around." Great for the programmers. An open checkbook and an audience too.
To be viable for the mainstream, XP needs to address the needs of the people who pay the bills. We must be able to show the C-level that we know what is