This post is pretty techie; my non-techie readers may want to ignore it. I promise I’ll try to be less esoteric.
You techies have probably heard all about Extreme Programming. I myself am familiar with the ideas, though I’m only begining to experiment with using them. I have not fully integrated test-first methodology into my development habits, but I do operate in a highly iterative fashion as I write code. I can see the benefits as I alter my habits and move in that direction. I think the coding and testing XP processes look generally salutary.
The problems I see in XP are more at the front-end of the process, working with business stakeholders in a highly iterative and interactive fashion. There seem to be some assumptions there:
- that software developers can function well as business analysts: That they can communicate effectively with non-technical personnel; that they understand the business of the customer; that they have well-developed business sense;
- that management is willing to cede some authority/accountability in favor of the flexibility created by a more give-and-take relationship between IT and its customers;
- fundamentally, that political boundaries between core business and IT organizations–internal and external–are essentially superfluous.
I would like to work in an organization where these assumptions are true. But my experience indicates they don’t always hold. If these assumptions hold in your organization, you’ve already solved or avoided a bunch of problems much more difficult than anything XP addresses.
The gurus who came up with XP seem a little shortsighted. A lot of methodolgy movements seem to spring out of the “hey, this thing works, lets bottle it and sell it” impulse; it’s interesting to note what someone chooses to put in the bottle.