TDD only works for extremely well-specified requirements. E.g. you are writing a server for a very well-understood protocol, or writing some code to perform so

TDD only works for extremely well-specified requirements. E.g. you are writing a server for a very well-understood protocol, or writing some code to perform some very well-understood algorithm. These are easy to test because there are very clear & totally unambiguous answers that the software has to answer. You can very easily write test-cases then because you already know precisely what the software should do. In reality for a lot of "enterprise" software I have been involved with, I have found that there is very rarely a specification that is that well thought out enough so that all of the answers (...or even questions that need to be asked) are known before any code starts to get written. The specs are usually super-high level (e.g. "the user should be able to update their preferences") that most of the details are left as an exercise for the developer implementing it. I'd wager that if you are in the situation where you have such a clear and concise specification before any code is written, then you're not actually agile at all and instead you are in some lethargic ossified waterfall where it has taken 18 months for The Committee to sign-off the specs for exactly what the widget will do when the user specifies that their preference is for home delivery but they have not entered a postal address yet but they do have a grandfathered-in address from the pre-aquisition database that can be used when the terms-of-service-acceptance bit has been flipped, but not if they are in EU and have not flipped the GDPR-acceptance bit yet etc etc etc. And if you are in this scenario, then some TDD ain't going to help your velocity. Real life is messy. Don't get me wrong, I am 110% in favor of unit tests. I just don't think that for the vast majority of projects that there is enough detail in the specs to write the tests first then stop when all the tests pass.