TDD by Example is a master piece of Kent Beck. Excelent book with examples of this development methodology. I'd say that TDD is not that good without an architect, as usual, because you've got to decide the API, the interfaces you want as you write the tests and that is a matter of experience.
Ron Jacobs talks very often about his colleague Peter Provost. Peter gives a brilliant point on TDD in this video.
More links regarding TDD:
When you got the feeling that you don't know what to test next or how to face meetings with customers, you can try a more specific way of TDD called Behavior Driven Development. Well, that is my understanding of BDD but I haven't read enough.
Update: (December 12, 2008)
Behavior Driven Development is a step further TDD. BDD is useful when you need to test the behavior of your function. Say that the method you're testing is saving some data into the database in some cases, but it returns "success" for this case and also "success" for the case where it does not need to persist any data. When you write the test for such a case, you can't just assert on the returned value. You've got to ask for the behavior. This is a perfect scenario for BDD. Same happens with access to files in the filesystem. Mock objects are a key tool for BDD as they allow you to test behavior without actual database persistence or files access. You can smell BDD when the thing you need to test goes beyond testing a returned value. Sometimes, I like to call BDD, pseudo-acceptance tests, because to me, they are more than unit tests, but still not acceptance tests. They are getting closer to the actual work flow of the application, they are really useful. I'll post about this in the near future.