"We need to do TDD" said the client.
"Our team is not producing quality code, and aren't performing up to our expectations."
"So, we need to introduce TDD to make sure we get what we need."

Uh-huh I thought. Thinking to myself... so, why aren't your developers producing quality code? What are they doing instead? Are they even unit testing at all now? Do they know how to test or are unit tests just an afterthought? oh yeah, and are there any other methodologies you need to add for your team to be buzzword-compliant!?

TDD is not just a buzzword. TDD is not just a methodology a team can adopt if they are in trouble. Not hardly. TDD is the top of the pyramid. It requires a mind-shift that is not tremendously difficult, but at the same time is very difficult to accomplish without discipline. Not every team is ready for this step. I would hope to have a cohesive, collaborative, and performant team, teach them how to write good tests (first or last), show them how acceptance criteria can be automated into tests that guide the team toward completion. After going through all of these pieces, I would then introduce TDD as a small thing, and the discipline required would probably already be there at that point.

While it may be in vogue to say a team is "agile" and uses "tdd" (note: here in lower case) it's much more important that a team is producing quality software - buzzwords or not. I am not exactly advocating non-tdd practices, but on the other hand we need to be practical about delivery also. If a team can truly do test-driven development, then congratulations I say, they are well positioned to be at the top of the heap. If not, I would try to lead the team in the direction to be ready for TDD, whether or not it gets used. Strong unit testing along with other kinds of testing will deliver the quality that customers need. So, evolve. Learn, Test well. And, if you can, use TDD.. it's great!