This post originated from an RSS feed registered with .NET Buzz by Darrell Norton. Original Post: Is Agile for "better" developers? Feed Title: Darrell Norton's Blog Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx Feed Description: Agile Software Development: Scrum, XP, et al with .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Darrell Norton Latest Posts From Darrell Norton's Blog

Mr. Ed, over on Hacknot, has recently written a post on oral documentation. The post is more of a story of a really screwed-up company, which can be seen through subtle clues about the company Mr. Ed is working for.

In the comments, Mr. Ed makes the following statement:

I think there are a few reasons for the characterisation of Agile approaches as being for "better developers".

1) It provides a catch-all caveat when weaknesses in an approach become evident. Whatever holes are exposed, there is the ever-present assumption that developers of sufficient ability will be able to plug it.

2) It creates a sense of exclusivity, so that Agile proponents can identify themselves as members of an upper class in the development community. Cults often characterise their members as being amongst the chosen few.

I would've thought that any proposed approach to development should be out to help people overcome common human failings and imperfections, not relying upon the practitioner being of superior ability.

Regarding number one above, the success of any project is usually due to customer involvement and the quality of the developers regardless of methodology used. That has been the consistent finding of the CHAOS report for the past 20 years or so. The exact same statement can be made about traditional methodologies.

Now I’ve never embraced the religious aspects of Agile Methodologies (AM) that he remarks on in number two, so I discount that part of his argument. Pragmatic developers, and those able to think on their own, will be able to ignore the hype surrounding agile.

The last statement I really don’t agree with. By nature, any approach that overcomes human failings limits those of better ability. In order to ensure consistency, you force everything down to the same consistent level of mediocrity. It happens at every firm as their software development practice gets larger (similar to consulting firms with their methodologies).

And, thinking back to the CHAOS report, since the talent of your developers is one of the two main factors for project success, why spend much energy at all making sure you have a fail-safe methodology? Spend your time and money on improving how your developers work with a repeatable (minimal) process, and turn them loose on challenging problems.