Dogma-less TDD and Agile

TDD is about rapid feedback of the code to the developer.  Agile is about rapid feedback of the application to the development team.

Everything else is just BS.

Here are some of the things that fall into the BS category:

• Up front design
• "Architecture"
• Project plans
• Estimates/Story Points
• Information Radiators
• Team Velocity
• Specifications
• Code Reviews
• QA
• Approval processes
• 100% Test Coverage

It's not that these things don't have a purpose, or aren't useful.  But they are all afflicted with varying degrees of BS (baseless guessing, built in uncertainty, outright lying, and occasionally even complete denial of reality).  

What most of these things have in common is team organization.  A one man team doesn't need this stuff. But any more than one person, and you require some way of keeping everyone on the same page.  Especially if you are building software that all of the teammates don't completely understand.  Without some kind of organization, people would be chasing their own ideas in all different directions.  And since they don't fully understand the "business," those ideas are likely to be wrong (or at least partly wrong).

Thus, teams need a certain amount of BS.  But I think it's important to remember the distinction.  The most important thing to delivering real value is feedback.  Feedback in code.  And feedback in features.  You need the BS, but apply it carefully, and try to keep the BS out of your feedback loops!