Well I guess I'll have to go ahead & disagree with you.

It would seem that programmers who have had the benefit of coding in a vacuum or in small teams at best tend to chafe against structure. It's tough to be a code-cowboy when you have to face rigorous peer code review.

What confounds me is how poorly received new development methodologies are when the point of them is to solve long-standing problems.

I'd say the most relevant thing about Agile development processes is that they embrace an iterative development cycle and poo-poo the traditional waterfall method.

This offers an opportunity for an institutional method to be introduced to reduce the effects of feature-creep. By developing in iterations you can hit the target that keeps moving and not have to look like you slipped your deadline each time the rug gets pulled out from under you becasue someone changed the project specification. It actually holds those people making the changes accountable for the impact on the deadline & the bottom line. How is this not a Good Thing?

What the processes DON'T do is to effect your coding style. They don't tell you how to think to solve problems, they don't tell you how to achitect your code and they don't assign you a serial number etched into your forehead after they shave your head...

Agile methodologies are more about Project Management than about code. While I agree that it is somewhat untastefully policitcal what you have mentioned with respect to forcing you to learn on your own time with the implied threat of losing your job (or at least access to the sexy projects) - I also will point out that as a developer you need to do that anyway. You shouldn't be waiting for someone to prod you into learning about new things. You should actively search them out yourself. Our industry changes constantly & to stagnate is to die. IMHO we simply no longer have the luxury of being a "heads-down-programmer." You need to constantly reinvent yourself.