Michael McDonald's Blog

Getting Things Done

Since I have had some free time on my hands recently, I have been hitting the books to sharpen my skills and learn some new ones. My latest focus has been on reading Getting Things Done and implementing it. I had my reservations, as I have doubts about most self-help and planning books: they are usually incomplete (creating more problems than they solve), too rigid (everything adds up nicely but the system is unusable by human beings), or too soft (lofty reminders of why you are here and what you want, but by the end you still don't know what to do next).

Getting Things Done definitely has some built-in bias: David Allen obviously has a manager-type work load. Beyond 2-minute or less tasks, his examples include lots of collaboration tasks (conferences, meetings, phone calls, etc.) and planning tasks (preparing a presentation... for a meeting). Managers and executives will immediately be able to relate to David's examples, but it's a bit more of a stretch for software developer. Fortunately the system is pretty universal and can be applied whether you are a CEO, software developer, or an actor. It just takes some faith and careful attention to subtext.

A good piece of advice that anyone can use right away is that whenever you come across some task that will take less than 2 minutes, do it right away. Why 2 minutes? David estimates that 2 minutes is the turning point where recording (and organizing and retrieving) the action will take longer than performing the action right now. 2 minutes is a beginning guideline, and may grow or shrink depending on your current mode, energy level, and the efficiency of your organization system.

The reason 'Getting Things Done' works is that it is a super-system. Instead of telling you how to arrange your calendar or day planner it tells you why you need one in the first place. It encourages 'hard edges' between types information: separating reference material from actions, getting rid of things that you don't need, separating 'must do' from 'someday/maybe', separating projects from next actions. Incoming items are quickly sorted among different systems, and the implementation of those systems are up to you.

These ideas appeal to me as an agile software developer.

There is abstraction and encapsulation: if you don't need to see something, it is hidden from view. That conference packet is filed away in a 'tickler' file so that you can decide whether you are going to attend at a specific future date. When action#2 depends on action#1, a Project is created and you only see/consider action#1. Reference material is not actionable so it is filed and can be looked up at any time.

Don't Repeat Yourself. When everything has been captured in the system, you can stop thinking about the same things over and over again. Making a decision is an action, so you can stop worrying about those 100 undecided questions and handle them one at a time. You never have to make the same decision twice.

Task triage is represented: incoming items are sorted into must-do, might-do, and will-never-do sub-systems.

Getting Things Done is like Test-Driven Development: define the task before doing it. The granularity of tasks/tests are determined by confidence/familiarity. By capturing both the steps (next actions, unit tests) and the desired outcome (unit tests representing stories or use cases) in an external system, the mind is emptied and you know what you need to do next.

That last point is the most important one. Whether you are writing a program, planning a presentation, rehearsing a play, learning a new dance, or practicing aikido, your goal is to develop external systems, physical instincts, and your own subconscious so that your conscious mind is empty. That is when the work become "effortless" and the dancer becomes the dance.

link  |   |  2/16/06 12:55pm
home  |  acting  |  blog  |  consulting  |  noel  |  contact
© 2013 Michael McDonald, . All rights reserved.