The most important part of TDD to me is what TDD actually is supposed to be, Test *Driven* Development.
Write the tests to the spec for the module. In the process you think of pass and fail scenarios that you probably wouldn't have just by writing the code. Then write the code. The developer should write the test and code in my opinion as it keeps their mind focused on how to write the code bearing in mind the things they were thinking about writing the test. The resultant code will be better quality than jumping in to write the code or having different people write code and test. And for the love of god, don't let a tester write unit tests!
Then, unit tests aren't TDD, though they can be used in TDD. The main benefit outside of TDD for unit tests is as a regression test. So long as you run them. Ideally run on every build.
Anyway, as for Agile, the problem isn't the original principle of Agile, but that anyone tried to control it with processes and meetings. SCRUM and the like are exactly what Agile was trying to avoid. That said, I quite like the Sprint approach, at least in that you agree with everyone, including stakeholders, what will be in the next sprint release. Once agreed, no manager can say "we must have this quick change now, drop everything! Though I still want everything else". It's not agreed, tough. Next sprint you can have it. To me it's a way of developers keeping control, not managers.
Where I've seen Agile fail is with too much process and management, and a lack of involvement by all stakeholders, which should go right to the top. That and people who just say "we're agile now" but don't do anything agile at all.