How much or what parts of the value of using TDD is dependent on the development process being agile or iterative, as opposed to a more waterfall-based approach, which may indeed have a "unit testing phase" (that a previous poster mentioned)?
(Assuming that the process isn't so strict that it actually enforces coding production code first and then producing unit tests after the fact, but allows development and unit testing to proceed simultaneously.)
<i>The lyf so short, the craft so long to lerne.</i> --Geoffrey Chaucer (c. 1343-1400)
To make a blanket statement, I'd say that the overall development process doesn't matter--you can still use TDD and benefit from it. It's just that the effects of TDD might be hidden by the bigger improvements or problems brought forth by the development process.
I'm curious about what you're thinking? Do you have a differing argument in mind?