Blog posts with splashy titles seem to get great hits so I figured I'd throw a little Trump on it :-)
I have always been impressed when I hear a shop runs pure TDD, it always seemed so put together. I had never seen it work, but I held out the hope that it could somewhere, somehow. I have heard recently of another TDD shop burn and fail. At this point, I am sort of a new product specialist, having done them at small and large companies. I have never seen a group of engineers get in a room and want to start with tests. Everything is so new and changes so fast, developers need to prototype and experiment to a point that gives them confidence that an approach will work. Managers want dates, and try to jamb arbitrary sprints, always the same size with the mystical "done" at the end of the sprint.
I propose a new form of managing projects that reflects the reality of new, innovative products. DDD. Down-Driven-Development. The spirit of agile is centered around small, demonstrative deliverable software. Our sprints should reflect these "Downs" (think football downs) so that developers work towards the things that they MUST anyway, throwing out the whole "documented deliverable don't touch it after" stuff. You might have 2 downs in a month, or maybe just one. This way the developers don't have to run an underground process and try to make it look like they are done each sprint, and they drive towards getting something working and improving their understanding of the space.
The first down might just be setting up tooling, or a development environment, or prove a concept will work. That's great! Just keep moving towards getting a set of ideas coordinated that work, no matter how ugly it might be. It's going to change anyway, and I really get annoyed when anyone in the chain starts blaming people downstream because something isn't "done". Guess what - no one can predict or know everything in advance, just take what you know, and drive to the next set of sticks.
The last few downs should be towards productizing, scaling and hardening. And if a developer says "hey I need to refactor this whole idea now" - embrace that. There is no way to predict and size all of the different issues that may arise when you mix 4 or 5 new technologies in a new environment.
I feel DDD is just a new twist on the spirit of agile development. No one process will fit all challenges, and only through experimentation will you find what works for you, and to get there, drive to the next FIRST DOWN!