Why I Passed on Agile/XP... at least initially

I've been talking for a bit now about Agile and XP software development practices. I mentioned that many developers first learn about Agile practices by reading Kent Beck's series on Extreme Programming (XP) or stumbling across the myriad of articles on the Internet about Agile/XP. For myself, this is how I first got introduced to Agile. I bought a series of XP books, and plunged into some long nights reading and digesting the revolutionary ideas around Agile.

However, like most revolutions, they force drastic changes in established practices that people follow. Sometimes this is necessary. Especially in software development, the practices of the last 20-30 years pushed by project management experts that if we only spend enough time on requirements and design all will be well, have been discredited by emperical evidence (late projects, failed projects, etc) and needs to change. Clearly what we've been doing hasn't worked too well in the general case. But getting people to willingly change what they're comfortable with is a significant challenge.

Although I could see how XP practices could help a development team get software written faster, I was hesitant to adopt it for the following reasons:

Developer resistance to Pair Programming
A key method in XP to increase the quality of generated code is to double up on the implementation by pairing developers. This includes pairing for the architecture, design and eventual coding. For certain profiles of developers, this can work really well and there are groups for which it does. However, there are also excellent developers that resist the notion of writing software this way. Although the true believers might state "then you need new developers", for many projects this is simply not an option. People accumulate knowledge about software over time, and companies cannot afford to be cavalier about seeing that knowledge walk out the door. The problems mount for any development manager if the developers who are already resisting this aspect of XP, have personality conflicts when working in such close quarters with their team mates. The question for any development manager here is whether the gains from XP Pair Programming outweight the inevitable turmoil it will cause to the existing team especially a team that is new to Agile in the first place.

Lack of Cross-Functional Emphasis
XP is definitely an Agile practice. However, it was created by developers and focuses on problems developers have in creating software. Other members of the software team such as Quality Assurance, User Education/Documentation, User Interface Design, DBA, etc are not specifically included in the XP framework. They can be fit in, but how they fit in isn't stipulated by XP. On projects I've worked on, the developers may have a huge say in how the software is built, but they rarely get to say when it is shipped (that's QA), how to present it to users (that's UI design), or how it's described (that's User Education). The software isn't complete until these other parts of it are also complete.

I had some other concerns around how to do Test Driven Development when maintaining large applications that have no history of unit tests nor an easy way to create them due to the particulars of the technology. But this was a lesser concern compared to the others I mentioned earlier.

So I put Agile/XP on the "interesting, but in a holding pattern" part of my bookshelf. And there it sat for quite a while, years in fact. Every now and then I would return and speculate on ways to introduce Agile/XP to the team without destroying it in the process.

And then I stumbled upon another Agile process called Scrum.

Next time, I'll talk more about what I like about Scrum and why it fits better for me than a pure XP approach does.

Technorati Profile

Posted by Mark M. Baker at 03:27 PM  Permalink