Microsoft has [published empirical data](http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf) that shows that the process overhead for TDD increases the development effort by 15% - 35%. Despite the many positive benefits from TDD, we cannot possible consider anything that adds an extra 35% effort to produce artefacts the customer will never see as lean. Amazingly, people still try and associate this with "agile".
That was, more or less, exactly what went wrong with the social networking group with which I was involved. We were sold both Agile and TDD at the same time, and the contradiction between the people oriented development cycle of Agile (something at which I excelled at CompuServe), and the process-driven development cycle of formal TDD, is what doomed the project and made it limp along without a real direction. Nobody ever stopped to ask what the whole thing was supposed to do; their were just these modules, all encrusted with a half-dozen tests, each ensuring that the module it tested conformed to some specification that existed only in the tester's mind. My mind included.
I believe that some process is important, even inevitable. But I could see the inherent friction in the TDD and Agile development processes that paralyzed a company's forward development progress. I think the 37 Signals approach of "It's a problem when it's a problem" is one of the best pieces of advice I've ever seen, or as I put it, "I write code until I do something stupid, then I write a test to make sure I don't do that stupid thing again."