The conflagration of Software Development Management, GTD and simple lists

I should say right away that trying to join these different methodologies may be futile and result in something that is less then its parts. But, who knows? Maybe we can discover something new and better! Or, help others from making the same mistakes we do.

I’ve been giving the whole task management vs GTD thing a bit of thought. Spending time with Redmine I think I’ve got a way of looking at these two different methodologies, bringing them closer together. In Redmine one has several lists (bugs, features and support), which are all contained by a project. Each item on the list has some attributes, including priority, due date and others. In GTD you break tasks down into individual atomic bits. It seems like the traditional methods don’t reduce each item down as far. And they don’t have too. The level of detail that GTD wants is more appropriate for the individual rather then the entire team. Redmine has two levels of abstraction, Projects, and tasks. Using GTD you would have each task as a project, and further break it down into smaller parts. There would have to be a higher level, to replace the project level of the traditional tools. In fact it would be better to allow arbitrary nesting of items. One no longer needs a persentage-done attribute as you can track the number of sub-tasks completed.

There is a lot more to GTD, but this seems an interesting start.

Open questions

How to model the waiting for action? Each side of the task needs a separate task but some way to keep them linked. Assuming that they are both on the same system.

Priorities are tricky too. Although they are really just suggestions for how to order your task list. You could, by default, have the software move the task with the highest priority to the top of the list for that project - it would become the ‘next action’ (this is GTD speak - you always have a next action to perform).

The inbox and review would also need to be visited and thought about.

Examples

Here are some examples from a software development perspective:

• Build great todo Software.

  • Write Design Doc

  • Write blog post about ultimate list of features for a todo list

  • Write blog post about the connections between GTD and traditional PM methods (a-la Redmine)

  • Combine all thinking (in blog posts) into a single design doc

You could further break down each of these items - Writing a blog post might include some reading and othe research, which you might want to break out into its own thing - especially if it involves more then just google ;).

Contexts, which are one of the key elements of GTD, would be pretty similar for most software projects - @computer or @work. In GTD contexts are denoted by the ‘@’ symbol, and are used to group tasks by physical location or equipment (or lots of other things) needed to complete a task.