Can we apply David Allen’s Getting Things Done process to software development? If it can organize the hectic life of a Fortune 500 CEO, couldn’t it help out the lowly software developer? A recent blog post from a coder in the Google trenches, “Good Agile, Bad Agile” suggests to me, “yes.”

This morning, I read a post over at King Lud IC that seems to indicate I’m not the only one who read “Good Agile, Bad Agile” and thought, “hey, this could apply to gamedev!” Of course, there are already folks applying the Agile process to gamedev (notably, the folks over at High Moon Studios). From the sounds of it, they’re happy and successful. But, I know Clint (High Moon CTO) and Noel personally, and those are two guys who I’d expect could make any process successful. They’re dedicated, meticulous, and above all clever. How about the rest of us?

Like many web professionals and software developers, I’ve been lured by the cult of personal productivity. It’s rather ironic, then, that I’m also infamously considered a procrastinator and referred to by my parents (when speaking to their friends) as “extermely laidback.” Of course, I own up to both of those descriptions. Perhaps they’re the underlying motivation for my constant pursuit of a “better system”?

I’ve found Getting Things Done (or GTD as its referred to by those in the trade) to be an ideal system. It has some basic rules, some lose theory around those rules, and a whole ecosystem of software and blogposts guiding anyone wishing to embark on the journey. For purposes of this discussion, here are the basic tennets (cribbed from the 43Folders linke above):

• Identify all oustanding issues (close all open loops).
• Get rid of everything that doesn’t need your attention right now (delegate, defer, delete).
• Create a central repository for everything that works for you.
• Put stuff in the right place, consistently.
• Work based on time, effort and context (do the right thing at the right time at the right place).
• Repeat, and refactor mercilessly.

So, how do we apply these tennets of GTD to the software development process? Or more interestingly for the readers of this dear site, how do we apply this to game development (thinking of the indies)?

Identify all oustanding issues (close all open loops).

I find this one to be the most satisfying, the most fun. It’s the carrot that really gets the process moving along. It’s brainstorming, but with more depth and detail. You’ll want to make an exhaustive list of all design features, technology hurdles and content requirements. Don’t stop and do anything, and don’t spend too much time thinking. The goal is to make as complete a document (list) as possible of what needs to be done. Try to be as specific as possible, but don’t worry too much about the granularity (as that will solve itself later). You should be telling yourself, “if I don’t write this down then it’s basically like it doesn’t exist.” Make your thoughts tangible, or they’ll never happen.

Get rid of everything that doesn’t need your attention right now (delegate, defer, delete).

The three D’s: delegate, defer, delete. There are lots of details you won’t have to worry about. If you just starting your design for a new game then don’t fret over how you’re going to collect credit card payments when its finished. You can worry about that if and when you finish the project. If you’re the programmer and you’re not quite sure how the artists are going to produce all the content for the game, stop, delegate that to the artist and have them worry about that. This is all in an effort to save you from the fourth D, distraction.

Create a central repository for everything that works for you.

I’m using activeCollab, a web-based project management app (a free, self-hosted competitor to Basecamp). Basecamp is a great option as well. Large organizations often use Microsoft Project. I’m sure there are other options as well. A simple to-do list could work as well, but the less structured it is the more onus is on you, the user, to keep things organized and useful. The critically important thing is that the repository is something that you’ll use, and use often and regularly. As a result, I’d suggest using a piece of software that you’re in love with, if possible, and you want to have an unreasonable desire to go and use it at every chance (to close those open loops).

Put stuff in the right place, consistently.

If you think of a new idea, put it in the repository. If you run across a bug, put it in the repository. Whatever you do, don’t have multiple places for these things to be kept; keep it all in one, centralized spot. Don’t keep a notepad on your desk and promise yourself you’ll type the stuff up in a few hours or at the end of the day. Do it now. The advantage is that you get these “open loops” out of your brain so that your brain can be used for more productive things. Computers are great at “remembering” things, let them do the grunt work.

There’s one exception to this: the two-minute rule. If you can act on something in less than two minutes, then do it. The overhead of “using the system” isn’t worth it for something so small. Two minutes isn’t an absolute, but don’t stretch the exception too far or you defeat the purpose of the rule (as you start to get distracted!).

Work based on time, effort and context (do the right thing at the right time at the right place).

Multitasking is trivial with modern computers. While context-switching is one of the most expensive “atomic” operations a computer can perform, it still is well under a second. For people, on the other hand, context-switching is expensive, very expensive. It breaks “flow.” So, instead of just plowing through your lists of tasks in the order they come, divide them into “contexts” that dictate when the appropriate time is to work on them. This is particularly useful for the one-man-gamedev-shop where you wear the hat of programmer/artist/designer/producer. I’d recommend having contexts like: Photoshop, Websurfing/Research, Visual Studio, Level Editor. When you’re in a specific context, look to that “list” to see what you should do next.

Also, if your “master list” tracks such useful information such as estimated time required for a task, use that information to as a secondary criteria for context. Have 15 minutes while you wait for some software to download? Do a little websurfing/research. An hour while your significant other is getting ready for work in the morning? Finish the icon for your application in Photoshop.

Iterate and refactor mercilessly.

Consistency in applying these policies is what makes them successful. Refactoring is also a big win.

Now, I don’t mean refactoring in the software sense. I mean refactoring the process. Part of the advantage of the simple process and the whole GTD system is its kind of introspective nature, where GTD practicioners are always looking for ways to refine and enhance the GTD system while still embracing the fundamentals of GTD.

But there’s an even more particular way in which you should apply the ideal of “iterate and refactor.” In the case of your master list, you’ll inevitably have items on it that the GTD crowd calls “projects.” Projects are tasks that are in fact meta-tasks, something like “Organize the Closet” which aren’t really directly actionable. When you hit upon a “project” in your list, you need to look at it and determine what the “next action” is, i.e. what can you do tangibly to move this forward.

In fact, GTD has “reviewing” as an important element of its process. One should regularly (daily, twice-daily) review all of the meta-level stuff, like projects, and determine where they stand (completion, timing, etc.) and populate their master to-do list accordingly. Again, this is an aspect of the “refactoring.”

Well… there’s a ton more I could write on GTD-as-software-process, and I certainly plan to do that. This post is somewhat vague in areas, a bit hand-wavy in others… it’s my first shot at getting these ideas down, but I’ll definitely revisit it in the future.