Is GTD the "Extreme Programming" of Time Management?

A few years ago I introduced our research lab to Extreme Programming (XP), a somewhat controversial software methodology with some surprising practices. This has worked out great, and as I continue my GTD exploration I've noticed some parallels between it and XP, which I wanted to share.

Most of these observations stem from considering the "extreme" aspect of XP - pushing software engineering best practices to their logical limits (turning the knobs to 11, if you will). For example, if code reviews (the practice of going over a program line-by-line) are a good idea, then do them continuously (Pair Programming). I think David Allen has done something similar in Time Management. Here are a few examples:

• If it's good to write things down, then write everything down, and work to keep it 100% out of your head all the time (GTD's Collection phase).
  
• Instead of reviewing your work and life during major life transitions (e.g., promotion, move, pre-vacation), review it all every week (Allen's Weekly Review).
  
• If "divide and conquer" helps us make progress on problems and prevent procrastination, then break every problem/project into its smallest atomic moving parts (Allen's Next Actions lists).
  
• If occasional free-form idea capture sessions are useful (say during crises or "creative" periods), then do them at least once a week (Allen's Mind Sweep).
  
• If eliminating the urgent is a good idea (Covey's Quadrant II - Important but Not Urgent), then completely do a way with A/B/C priorities, assume everything is important, and work opportunistically (Allen's four criteria model).
  
• If learning to say no helps manage commitments, then keep an up-to-date list of every single commitment in your life, review it regularly, and keep it in mind when considering new ones (GTD's projects list). Also, be flexible and renegotiate commitments as needed (Allen's Someday/Maybe list).
  
• If planning your work is good, then plan all the time, i.e., every time you have discretionary time (GTD's daily review).
  
• If clutter is posponed decisions, then collect everything into a small number of collection points, and make decisions about inputs when they enter your life (GTD's zero base).
  
• If we often have "odds and ends" time, then always be ready to get something done during that time (Allen's portable Read/Review folder, and his @Anywhere context).

Some other XP/GTD parallels:

• XP asks "What's the simplest thing that could possibly work?" GTD asks "What's the next action?" and "What's the successful outcome?"
  
• XP says to Refactor Mercilessly. GTD allows continuous tweaking of your implementation (not always good!)
  
• XP's Test Driven Development turns code testing on its head - instead of writing correctness test after the code is done, write them first, allowing them to drive the code based on your goals. This is akin to GTD's outcome focus approach, which also protects us from doing too much by start with the definition of (wild) success, and using that to determine when a project is done.

Can you think of other parallels? I'm sure I've missed some. Cheers!

Comments

[Neal]

This is a great post. As well as being bang on the mark as far as the comparisons are concerned, this is also the best overview of important GTD concepts that I've seen in a long time. Thanks very much for writing it all up.

[Matthew Cornell]

Thank you very much for the compliment, Neal, and for reading my blog. Made my day!

[david douthitt]

Thanks for the excellent posting. I follow you pretty closely, and read daily [GRIN]

Since I'm a computer system administrator seriously considering a home business as a professional organizer, I watch your excursions into personal coaching with some interest....

[Matthew Cornell]

Thanks for reading, david. Much appreciated. I'd love to talk sometime about what you're doing. Feel free to email me to set something up, if you're interested.

(BTW, I'm a LISP person from way back - I programmed Symbolics and TI Explorer lisp machines back in my NASA days, writing model-based control and monitor systems for ground operations. Good stuff!)

[Des Paroz]

Outstanding post Matt. Neal said what I was thinking - that this post represent a wonderful summary of some of the key principles of GTD. Thanks for sharing.

I am not a programmer, but I have a number of them in my team - I am going to refer them to this post so they can get a good analogy on how and why I do things the way I do, wrt to my personal productivity system.

Thanks!

[Matthew Cornell]

Thanks, Des; very kind of you. I'd like to hear how it goes talking with your programmers. I'm interested in the intersection of XP and GTD coaching, as I may have mentioned. Thanks for reading!

[Pascal Venier]

[ ... Now is GTD really about time-management? | http://venier.blogspot.com/2006/01/now-is-gtd-really-about-time.html ] ;-)

[Magicfuture5]

Very interesting post Matt. Has made me wonder whether there are areas where XP could, by analogy, improve your life. Maybe the thought processes and techniques apply equally well to goal setting/achievement generally for exanmple. Hmm...food for thought.

[Matthew Cornell]

Thanks for the comment, Magicfuture5. I like the idea of applying XP to life. Hmmm - We've got Extreme Programming, Extreme Sports, why not Extreme Life? "Living each day like it's your last" might give some interesting perspective?

[Matthew Cornell]

I'm glad I can continue to trust you to push on (and question) the assumtions, Pascal. I liked your post (more comments there). Thanks!

[GadgetComa]

Wow. For a minute there, I thought I was reading a post by one of David Allen's coaches. Having been in software development for 15 years, your analogy really hit home.

In terms of the refactoring mercilessly, perhaps another comparison to GTD is the constant re-evaluation of priorities as you review Next Actions?

Also, I think there may be some use in reversing the analogy to get developers to manage time better, deal with the flurry of ideas that often happen while coding and more. For example, developers should write everything down that comes into their heads. Too often, they dive right in to coding everything they can think of. By writing things down, they can be sure the idea is captured while not introducing unplanned 'features' into the app.

[Matthew Cornell]

Thanks for your great comments and insights, GadgetComa. I really hadn't considered the other direction until you brought it up. I esp. like capturing programmer ideas as they come up, but not letting them distract. Great stuff! Thanks again for the kind words.

[Jeff K]

Another example of GTD taking a common organizational principle to a logical extreme:

"A place for everything, and everything in its place."

In Gtd, this translates not only to the obvious physical environment de-cluttering, and putting things in order, and where they belong, but to all levels of the GTD process. For example, don't mix Reference material with actions on a next action list. Don't mix discreetly defined next actions onto lists with otherwise un-processed 'stuff'. Don't mix project action reminders (sticky notes) with decorations (wall pictures or posters). Don't mix or combine different discreet phases of the workflow process. Don't mix current next actions with those to be done "someday". Divide up next actions into lists according to logical 'contexts'. etc.

[Matthew Cornell]

Hey, Jeff - I really like your insights; very nice. Thanks for reading, and commenting!

[Geri]

At last, someone that doesn't think this concept is crazy! I have consulted for entrepreneurs for over 25 years and have devised vast varieties of goal and time management systems. Each accommodates different personal styles and skill levels. As a result, I know 3 things for sure. 1 – the concept of SIMPLE is universally oversold and most people will choose “simple minded” solutions instead of looking for the “simply brilliant” ones, 2 – Planning in sufficient detail uncovers critical top level logic flaws that, if resolved in advance, would save significant time, money energy (and is therefore worth the effort) and 3 – most people would rather chew nails than focus on details for the required amount time (even to reach their own dreams).

So, for those of us comfortable with high levels of detail- yippee! The devil really does live there!

I have great hopes (and energy) for exploring this topic. It’s good to find kindred.

[Matthew Cornell]

Hi Geri, thanks for your amazing comment. I'd love to hear more about your experiences.