GTD versus TDD

I recently had the pleasure of reading (actually listening to) "Getting Things Done" by David Allen.  I'd heard great things about the book for a while now so when I noticed that my company had a copy in the company library I couldn't pass it up.

Although I wouldn't call the book necessarily groundbreaking, I did find certain parts of it useful and did indeed pick up a trick or two along the way.  However, after reading the book I can honestly see why it receives such acclaim in agile development circles.  In fact, I was almost immediately struck by the similarities between Allen's mantra of getting things done and the common rhythm of test driven development.  In other words: GTD versus TDD.

Let's think about it, GTD prescribes this common mantra (which I have liberally paraphrased here for simplicity):
1) Identify a concrete item that you need to do
2) Identify the very next action that you need to do to make progress on that item
3) Repeat

Now, let's look at the prescribed rhythm for test driven development (which once again, I have paraphrased):
1) Identify a feature that must be implemented and write a failing test to represent that feature
2) Do the absolutely smallest thing that you can in order to make that test pass
3) Repeat

Have I paraphrased the highlights of both topics and taken certain aspects out of context?  Possibly.  However, the eerie similarity between the two is hard to miss.  Both focus heavily on identifying concrete items which must be completed and both focus heavily on identifying the smallest set of discrete steps possible in order to complete those items.

Although, I doubt that Allen was inspired by the community of test driven development when developing his method I am beginning to understand why his techniques are so heavily lauded by the agile and TDD communities.