The reason for a lot of Agile code/practices is pretty sensible to me. IMO, the trouble is the language and process sometimes seem too dogmatic. I suppose it's a necessary evil, as creating common sense names for a specific practice that's intended to avoid legacy pitfalls that are too numerous to name, probably don't exist--so why not give them whacky names? If there aren't too many, I might even remember what they're for...

I've attended training on Agile, and it's funny to hear "experts" argue about problems and solutions that are found within the process. Often, like any dogma, it's left up to religious interpretation. There are faithful followers, zealots, agnostics and blasphemers. And then there's always some heretic that throws in his own set of scriptures or accesses some deep magic, and the conversations are all very strange.

But then, I suppose it's the price we pay for trying to avoid all the pitfalls of the past.

I've found a good general rule is to think of all these things as a way to help you stay engaged, while becoming better at what you do. If you're continuing to learn, you're doing something right. If you're doing process for the sake of process--then automate it or find a better way.