I have seen those problem countless times.

My suggestion is avoiding TDD at all if the team does not know how to do it properly. And, if they are not doing TDD, that means that they do not know how to do TDD properly.

And why I suggest avoiding TDD in those cases? Because they screw up with the tests. They do not really do TDD, or if they do TDD, they just write the test that forces the implementation that they had already in mind (focus on code, not on behavior). And the result is: either the tests don't work, or they are so tightly coupled to the code that they don't allow the design to evolve. So, they are valueless and the result a complete waste of resources.

I have seen some companies to focus it differently. Instead of wasting resources forcing developers to create tests that they dislike or do not understand, these companies do "team building activities" in which they develop, and maintain, small projects with purely TDD. And once programmers start understanding TDD and its benefits, then the programmers themselves start doing TDD in their projects.