... are not Herculean tasks only supermen can perform.

If you read down the other branch of the subtree from my initial post in this thread (the one you originally responded to) you'll find another of my posts (currently a couple of inches below this), where I say:

There is no substitute for competent (not gifted or clever) programmers, who work hard, to achieve the primary goal.

I wasn't suggesting that you were a superman. Just that you have "a well thought-through set of development procedures", and "the personality, drive and skills" to focus upon the goal, rather than theoretical perfection or academic argument.

Open source projects (in the absence of funding), are a peculiar beast as you are managing not budgets of money and commercial aspiration, but peoples (and your own) free time, interest and personal aspirations. You have nothing to leverage. No rewards to offer, nor livelyhoods to sanction. No pool of N x 40 hours with which to work. Your only means of inspiration and control are personal input (and sacrifice), effort and achievement.

The point is that if an incompetent or less driven person had taken over the project and attempted to institute XP/Agile development methods, they would have had far less success than you.

Equally, a competent and driven individual using a similarly well-thought through, but different set of development procedures, might well have succeeded.

To take this full circle. Pre-supposing a prospective employee as incompetent, because of their lack of exposure to XP and/or their inability to score highly on an "agility test", is capriciousness bordering on discrimination.

Equally, precluding a potential employee for a Perl position, because thay have little or no experience in Perl does the employer/project a dis-service. A competent programmer, with good experience, will usually get up to speed with a new language very quickly.

That "agility test" only scores people/teams on their adherance to the methodology--not whether they use it to produce a successful product. It is a self-serving, meaningless statistic. As with all these methodology cults, when the projects using it succeed, the advocates will attribute that success to the methodology. When they fail, they'll blame the team for using it wrongly.