In the trenches, methodologies don't get projects done. Dave Thomas's original description of agility seems an accurate description of how code actually gets made--and that description is deliberately not a description of a methodology. I ship working code every day, and my clients are happy, despite the fact that I'm not following any definable methodology. Coding is a messy process. Codebases evolve in many ways: They advance by leaps and bounds, they stagnate, they regress, they sputter along, they bloat--often all at the same time. Sometimes you write tests first, sometimes you code first. Sometimes you whiteboard first, sometimes you write up a detailed spec. How do you know what strategy to adopt at any given moment? You can try to formalize it all you want, but in reality, the choice is usually made on intuition.
That last point--the key role of intuition--is one of the biggest reasons you can't package up effective coding as a book, a manifesto, or a training session. Which implies something managers may find distressing: There is no silver bullet; a coding team's only salvation is smart coders.