There are two main schools of software development: those that love agile processes and those that don’t. Of course, there could be those that couldn’t care either way….
And both have very convincing arguments and both can be as passionate about their own [dis]beliefs. But just as soon as somebody hails a solution to our problems, there’s already another gang crying that the solution is the problem, or is the bigger evil of the available problem domains.
Wether you like agile process or not, benefit from mechanics of pair-programming or not, have had your ass quite literally saved by TDD or not… there will always be a process that you follow, however loosely [or not] defined and [not-so] obvious to the rest of the world. It is amazing how the n-schools of thought justify their existence by the apparent shortcomings of another. This is no surprise since the world operates in this fashion. Democracy rules because of the evils of autocracy. And vice-versa. There are not many, if any, systems which are self-justified. Agile processes rule because of the shortcomings of traditional development processes. Traditional development approaches rule because the alternatives don’t work. This is the mindset that pervades the path we choose.
The irony is is that if it works for one, it’s because it just works in that time and space for that collective group of people. Does it mean that it will work for another group of people, on a different project, with a different skill set and varying group dynamics? Of course, you’re welcome to say it will. You can also say it won’t. In other words, you can speculate. But no amount of speculation will justify how right or wrong you are about another group’s implemenation [interpretation] of the same principles.
What works for one project works because the people on that project make it work. What doesn’t work, simply doesn’t work. None are so blind and deaf… And with methodology, nothing will make it fail as much as those who don’t want it to succeed.