I think that, ironically enough, it can.
I interviewed at some anonymous company that was big on XP (aka “Extreme Programming”): pair programming, test-driven development, etc. One thing I will say is that they did a very good job if interviewing, giving candidates an actual opportunity to try the techniques they use out.
And one thing that struck me about test-driven development was that it makes it very difficult to write code in a bottom-up fashion. The basic response was something along the lines of “you just don’t do that.” Lovely. A powerful and productive technique that you “just don’t do” because the methodology you have required people to adhere to does not allow for it.
And what if programmers sometimes come up with better ideas on their own? Sorry, no can do, either. Pair programming doesn’t allow for alone time.
“Sorry, we’d like to incorporate that feature change, but we’ve frozen the feature set because the software is now in alpha test. We just can’t do that.” Funny how the supposed diametric opposite of the traditional waterfall model ends up sounding so much like it.
The problem here is one of taking rules too seriously. Any set of rules — it fundamentally does not matter which ones. You cannot fix such a problem merely by choosing the right set of fixed rules, no matter how enlightened the motivation behind the choice of them might happen to be.
If you can’t make exceptions for exceptional cases, you’re going to end up sometimes forcing people to act like stupid robots, doing something suboptimally because that’s the only way The Rules allow for it to be done.