TDD is like bumper lanes at a bowling alley. If your goal is to knock down the pins, it can help prevent problems, like falling in the gutter.

Of course, if you're incredibly good, you don't need the bumpers. You might even forego bumpers to show off that you are -that good-.

Your solution is to make all the bowlers really good. Here's the issue - historically, that doesn't scale across a growing dev team.

Imagine 5+ bowlers all using the same lane. The more bowlers you have, the more you will have balls bumping into each other, getting in the way, crossing paths, and falling into the gutter.

As you increase the number of developers, the more likely it is that tools like TDD and Source Control can help mitigate issues that inevitably arise on a larger team. They aren't silver bullets to great programming, and they aren't a bandaid to cover up bad programming. They are time-tested, proven ways to get people going the right direction.