"Can we put this effort into making programmers better faster and stronger? Agile purveyors act as if they have an army of superhuman programmers already at their disposal and the only goal is utilizing them correctly."Interesting observation. It raises all sorts of interesting questions, such as “what is better?” Really though, what is a “better programmer?” How do I know which programmers are better than others? How can I measure that? Is it the ones that produce the most lines of code? Is it the fewest defects? What if a programmer produces no defects, but very few lines of code and the code that they do produce isn’t used by anybody? How do I really know that it has few defects if it isn’t used by anybody? Perhaps the tests that would show that it is defective weren’t written because, again, nobody cares about that code?
Let’s ignore the problem of comparing programmers and just assume that I have found a training regimen which creates better, faster, stronger programmers. If the programming effort of each individual was the only thing that determined the success of a project, we’d be all set, wouldn’t we? But most projects consist of at least two or more people interacting according to some sort of process. Many projects have nebulous goals and/or requirements. Quite a few projects get cancelled or shelved, either because they were clearly headed for failure or something more interesting came along. And let’s be honest about those so-called “shelved” projects. Do they ever come off the shelf? Don’t we just start over when we get back to that project?
All of this adds up to a system which has complex and unpredictable behavioral characteristics which are different than the sum of its parts. It isn’t enough to invest in better, faster, stronger programmers if the result never sees the light of day. Before investing a penny on any improvement project, wouldn’t it be better to have a way to very quickly find out what problems exist and very quickly see whether or not a solution to a problem actually makes a difference?
Let’s face it, traditional development methods aren't very good at providing visibility into the true state of the situation, nor at providing feedback on whether anybody is actually headed in the right direction. Agile is not a silver bullet and won't actually improve anything all by itself. Simply put, Agile is an improvement framework. It will expose quite painfully where the problems are, it is up to you to recognize them and solve them.
Any time I talk to folks about Agile, I point out that there is no magical place to get an army of superhuman programmers. According to IDC, there are ~12 million programmers out there. Those programmers include you, the folks you work with, and millions of other programmers just like the ones you’ve met.
Whoever you have now is pretty much the team that you are going to have to go forward with. Sure, you can probably switch who you have now with other folks, but that's no guarantee that you will get "better" programmers, only that you will get different ones. Better figure out how to make the most of the resources you have. And while I am a big fan of training and self-improvement at the individual level, why not leverage that investment by improving the framework within which those individuals work?