Todd’s Practical GTD Agile Method

I love GTD, but it definitely has some issues that I don’t like. Here are some good links to learn GTD. I also recommend reading his book, or not. It’s long and boring actually. What I ended up doing is merging a few things between GTD and Agile. I’m definitely not any sort of Scrum Master or Agile guru by any means, but I do find some things useful about it when it comes to project management.

I use to implement my GTD / Agile Methodology, but my method is a little different and I will explain why. Come back here after you’ve read at least the first link above.

I organize by doing the following:

I use the tag system heavily. The folder system is too limited. If I want to categorize one item into two boxes I should be able to do so. They work exactly like the folders but it’s substantially more flexible. The folders just aren’t necessary.

My “someday/maybe” list is not one list. It’s several lists and I use the tag system for this. For example, I have a tag called “Japanese”, “Game Dev”, and “C++”. These are someday/maybe lists organized by topic. It’s better to have as little of these lists as possible. Inside of these tags are lists of non-active projects and tasks. Projects consist of multiple related tasks that I want to do but don’t have time right now and don’t want to forget about. For example, a project might be titled “read the C++ book I have on my bookshelf” and a task might be called “read C++ article at such n’ such website.” I might have a lot of items in here and I might even organize the miscellaneous tasks into a single project called “Get better at C++”.

I have daily “next action” lists. This sounds weird, but I’ve come to the conclusion that it’s not good enough to have a single list called “next actions” with every next action for all of your active projects in one single list. There are three reasons for this.

  1. It’s impossible to stagger projects. If I only have time to work on one project, I’ll always choose the project that is more fun and never make progress on the boring one.
  2. You can fix this by staggering the projects to be on different days so you will always make progress. The single list doesn’t allow for this. Not really. Instead of working on both projects every day for 30 minutes, it might be better to work on one project for an hour one day, then the other project for an hour the next day. This is difficult with one list.
  3. I no longer have to go through a list in the morning to decide what I want to do that day. It’s already pre-planned for me. In other words, I create a sprint of items to do for the week a week in advance. So on Tuesday, I don’t have to decide what to do, I already decided that the Sunday before (my review day). So on Tuesday, I click on “Tuesday” and just look at the list. No thinking required. That was done on Sunday. I never sprint plan more than one week in advance to maintain flexibility. It’s also less work.

Starred items are my inbox. So when I create a task, it’s automatically starred so that I know I need to review and sort them later. I review all of my starred items once a week and tag them and then un-star them. This systems allows me to shoot off an item, have it automatically starred, and I can just forget about it until my next weekly review session. I can worry about it then.

My weekly review is my “sprint planning meeting”. I decide what I want to work on, I organize and tag the items and every day I schedule a set of tasks to be “due” on that day. So I can click on a single day and boom, that’s my todo list for the day.

Priority and contexts are used to help organize things for the day. It’s not necessary, but it breaks things up for me. For example, I use contexts to organize things on a time basis, like “@01_before_work” or “@02_lunch”.  This basically gives me a sorted list. If I have multiple items that need to be done at lunch time, I can sort them by priority as a secondary sort. So essentially, from top to bottom, I just work my way down.

I attempt to guess the amount of time a task will take and I fill in the “length” field for each task. At the bottom of the day, it totals the amount of time all of my tasks will take for that day. I know if it’s >4 hours, that’s probably pushing it for a single day. I can also highlight a whole week within toodledo’s calendar and it will total the entire week’s worth of tasks. I know I need to move stuff around or pull if off my next actions lists if it’s >20 hours of work per week. But the more you use it, the more you’ll be able to guess how much work you can take on without burning yourself out.

One problem I have with GTD is that it doesn’t account for projects or tasks that don’t end. For example, a project might be “Get to know Jesus better”. So you’ll have weekly tasks that repeat called “pray” or “read one chapter”. I create a special tag for these called “habits”. These are essentially projects that never end or you don’t know when they might end since they have no well defined end result. But you don’t want them to clutter up your “projects” tag, which is a tag used to hold currently active projects you are working on that get scheduled throughout the week that have a definite end goal. If you can’t schedule it during the week, untag it. Each project needs to have a “next actionable item” and it needs to be scheduled on the calendar. You can choose to stop a particular “unending project” any time.

For some repeatable tasks, don’t create daily repeatable tasks because you can’t see the next one until you click “done” on it. For example, if you want a daily habit, you need to plan for the whole week. So create 7 items, one for each day, and mark them as “weekly”.

If I work through the entire week, I have checked off a bunch of items but I might see several tasks that I didn’t get around to doing because maybe I was overloaded or something else came up. If you recall, I said that I set a “length” property for each task. So you can highlight the previous week and get a total for the number of hours/minutes you didn’t get completed. This gives you a good idea of your velocity (how much you can get done per week). If I didn’t complete, for example 2 hours worth of tasks, I figure out why, and then I can adjust next week’s total task time -2 hours. This is the sprint’s velocity adjustment and it allows you to factor in things that maybe you didn’t realize you had problems with. Maybe you forgot that it takes you 30 minutes to drive to work but you failed to account for this time during your last sprint planning meeting, or it takes you 30 minutes to cook dinner. This is important because it prevents you from overloading your sprint. If you overload your sprint you’ll either burn out or get demotivated.

Comments are closed.