David Allen

Business 2.0 interview with GTD's David Allen

Merlin Mann — Thu, 28 Jun 2007 09:13:50 -0400

David Allen: The master of getting thing done - July 1, 2007

Terrific article on David Allen and his company. Although the perspective is heavy on the business and money (well: after all, it is Business 2.0), there’s lots of interesting history and insight in here as well.

David Allen sits in his small office in a cottage behind his house in Ojai, Calif., talking business with a visitor. Suddenly he stops. “That reminds me,” he says. He scribbles the words “bird feed” on a piece of blank notebook paper and tosses it into his inbox.

It’s an ordinary moment in an ordinary day. But for Allen and his legion of followers, it holds the key to salvation. He has emptied his mind of a nagging task, placed it into a trusted system for processing, and casually returned to his conversation.

I hung with David when we were doing our podcast together (download the mp3), and I’ll tell you what: that is exactly how the man works, and it’s inspiring to watch.

Via: kedrhodes’ bookmarks on del.icio.us

”Business 2.0 interview with GTD's David Allen” was written by Merlin Mann for 43Folders.com and was originally posted on June 28, 2007. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Merlin & Leo: Gentle introduction to GTD

Merlin Mann — Mon, 09 Apr 2007 07:20:46 -0400

The Tech Guy Labs - Leo Laporte, “The Tech Guy” [2007-03-31]

On last Saturday’s Tech Guy radio show, Leo Laporte and I talked about some of the basics of David Allen’s Getting Things Done system. For most regular visitors to 43 Folders, this is going to be very introductory stuff, but I think it may be useful to folks who are getting started or are just curious about what “GTD” even means.

My segment appears from about 00:59:30 to about 1:08:45. Here’s a link to an MP3 of the show, plus a few of the items that were mentioned in the segment:

Tech Guy Labs: 64k MP3 of the 3/31 show
43 Folders: Getting Started with ‘Getting Things Done’
43 Folders: Description of ‘43 Folders’ (tickler file)
43 Folders: Introducing ‘The Hipster PDA’
43 Folders: 8-Part audio interview with GTD’s David Allen
43 Folders: Best of GTD posts
Amazon.com: Getting Things Done, which is David Allen’s book that started it all

”Merlin & Leo: Gentle introduction to GTD” was written by Merlin Mann for 43Folders.com and was originally posted on April 09, 2007. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

HOWTO generate a kGTD Project list for your weekly review

Merlin Mann — Wed, 20 Dec 2006 09:01:22 -0500

While OmniFocus is under development (and yes, friends, I have seen it: it is actual software that does things), we Kinkless users will have to make do as we can for now. And while I still find my own kGTD setup oddly stable given its byzantine under-the-hood workings (think: innards of Cylon Raider meets Brazil’s pneumatic tubes), there are definitely times when I crave just a bit more canonical GTD functionality.

One of the most vexing shortcomings in kGTD (God bless it) is the lack of a formal Project list — one easy location to glance just all of the obligations and desirable outcomes that are on your horizon, without reference to the tasks that comprise them. David Allen has repeatedly said that the project list is critical (as I recall, his quote in our interviews was “…the Project list is king.”), and, honestly, lacking an all-in-one Project list for your weekly review is kind of like sitting down to the SATs without your two sharpened #2 pencils.

My solution for this has two components — one mostly behavioral and one mildly technical. Both are squirrely and lofi and your mileage may vary. As ever.

1. Brutal pruning

First, as part of my weekly review, I relentlessly weed from kGTD any Project that I know doesn’t belong there. This could include:

projects that died or have gotten cancelled or rescheduled
projects that have gone hopelessly and irretrievably fallow (functionally dead)
projects I have no real intention of working on (for at least the next month or two)
projects I’ve kept around because of sentimentality, affection, laziness, or just too much ambition

Bottom line: if the Project doesn’t have a legitimate next action that I intend to complete in the next couple weeks? Gone. Deleted or moved to “Someday/Maybe.” Next, please.

This, as David is fond of saying, clears the decks by removing any distractions or baseless claims on your attention. And while it’s not so novel a concept (everyone’s weekly review should include this step in some way), it’s critical for part 2 of my kGTD Project list hackination. (Plus, yeah, it just feels really good to do)

For our purposes, it also ensures that you’ve completed all the obvious pruning before creating your new Project list and delving further.

2. Copy and Paste

<background> As you add projects, actions, and contexts in kGTD, the AppleScripts that keep its lights on are populating the different parts of your document with multiple synced versions of your information. The ability to view, for example, just actions associated with a Project versus just actions associated with a context are arguably the coolest and most useful features of kGTD since it mirrors GTD’s ninja shifting between horizontal and vertical focus. </background>

But what it took me a fricking year to figure out is that I already have a project list — it’s just that it’s hiding in a dropdown menu.

Getting your Project List liberated

Backup your kGTD document, then do a Sync and Save
- Backup is good. Repeat, repeat.
From any Project or Context view, select the “Projects” column head
- Should be the third column after “Action” and “Context”
- After you do this you should see the column get highlighted (mine’s blue) with one of those pretty OmniGroup-y, rounded corner highlights
Reveal the “Column Type” Inspector window
- Either by hitting “COMMAND-3” or by selecting “Column Type” from the “Inspectors” window
- You should see two drop-down menus (“Type” and “Summary”) and then a big-ass bulleted list of all your Projects
Select the first bulleted item in the Projects list
Scroll all the way to the last item in the list, then hold down “Shift” and select that last item
- This should highlight all of the projects
- Again, you should see lots of those pretty rounded selection highlight thingees
Hit “Copy” or “Command-C” to snatch the Projects to your clipboard
Open a new, blank text document in the text editor of your choice, and hit “Paste” (or Command-V)
- (I like TextMate but TextEdit will do fine)

And that’s it.

“WOW, thank you: you’ve taught me to ‘copy and paste.’ So, now what, Admiral Obvious?”

The first thing you might want to do — depending on your personal brand of anal-retentiveness — is to tidy up your new Project list document a bit. Personally I Search & Replace all “…”s into TABs, which provides a prettier outline. At a minimum, get the document to where it’s visually sensible for you. Then print ‘er out.

Cosmetics aside, you do what you need to do with a project list. You let it jog your memory. You use it to find time sinks and attention holes. You scout for dead wood. You comb through it for missed actions, meetings you forgot to schedule, and reminders of things you said you’d do a week ago. This is your outcome-centric viewport into all the projects and actions that need to be added to or removed from your kGTD list. Be courageous.

“No, seriously. Why bother?”

I’ll just speak for myself here, but I think that once you’re out of the ad hoc procrastination mind set of the task list, you permit a more strategic part of your brain to take over for a while. Your mental CEO gets to take a crack at all the projects, deciding who gets the deep-six versus who’s not getting the attention or resources they deserve, and then you can return to your task list with a rejuvenated sense of do-ability, focus, and mission. I call it “Manager Mode,” and it’s something I really need.

Also, from a tactical perspective, I like to use the Project list as a way to identify my “focus projects” for the week. If you have more than a few dozen projects (and share my own dearth of non-computer contexts), you probably crave some way to narrow your focus. A weekly review of the list can give you the confidence to call out the stuff that must see motion this week. You can even use to pull up what Gina calls your “MIT” (or, most important task of the day).

Regardless of your approach and preferences, if you’re attempting some flavor of GTD, it’s well worth your time to generate a task-less Project list and review the crap out of it as often as you need to. Because, if you aren’t occasionally alternating between the tasks “on the runway” and the larger outcomes of higher altitudes, you’re not only not doing GTD; you’re probably wasting a lot of time and missing out on some cool opportunities.

Addition, 2006-12-20 10:08:27

Based on comments, I should clarify why a plaintext list of your current projects (without tasks?!?) has value in a GTD review (although David covers the concept nicely in the book, if memory serves). Thus, I will embrace vanity and quote myself at length:

The Project list — in David’s canonical description — represents the “10,000 foot” view. It should exist as a list unattached to child tasks someplace and then be reviewed and updated as a thing-in-itself on a regular basis. It’s not about the tasks per se; it’s very much about evaluating how your Projects map to what you want to be doing at 20k [feet] and higher.

My gut sense is that a lot of the folks using kGTD use it as a fancy to-do list. Which is in a sense, what it is. But you mustn’t just stop there. It’s critical to not spend your whole life shoveling tasks and vaguely hoping that they map to some kind of outcome. That’s the Bad Old Days simply relived with updated software.

IMHO, GTD works best (and only) when you periodically take a formal step up and off of the runway to ensure the projects themselves are worth doing (and have a place in your bigger plan).

I love that the weekly Project review also generates new tasks at the runway level; but that’s mostly happening specifically because you set aside the time to not focus just on the stuff that’s already in front of your nose.

”HOWTO generate a kGTD Project list for your weekly review” was written by Merlin Mann for 43Folders.com and was originally posted on December 20, 2006. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Productive Talk Compilation: 8-episode podcast with GTD's David Allen

Merlin Mann — Tue, 28 Nov 2006 09:05:34 -0500

Productive Talk Comp.: Episodes 01-08 on Odeo

As promised, here’s the single-file compilation of the Productive Talk podcast interviews I did with David Allen, the author of Getting Things Done. The final version’s eight episodes clock in at a considerable one hour and twenty-six minutes, so this should give you plenty to listen to while you’re in line at the DMV.

Some editing misadventures stole the time I’d set aside to write up my final comments on the series, but those will be coming along soon, I promise. In the mean time, as I said in the podcast ep., I want to sincerely thank David, Rick Kantor, Robert Peake, and Zircon Skye Studios for their participation and help with the Productive Talk series. David in particular was unbelievably generous with his time, and I’m very grateful to have had this opportunity to interview him.

Hope you all enjoy hearing the whole series, in order, all in one place. There’s some nuggets of GTD gold in there, if I do say so myself.

Please note: the version included in the podcast feed is a lowly but compatible MP3 file; Apple-y folks with iPods and sexy AAC support can grab this tastier m4a version, which includes chapter markers that make it easy to flip through the individual episodes quickly.

You can learn more at Odeo.com, download the MP3 version, or just listen from here by using the Flash player below:

”Productive Talk Compilation: 8-episode podcast with GTD's David Allen” was written by Merlin Mann for 43Folders.com and was originally posted on November 28, 2006. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

David Allen on GTD's future (and why it just works, as is)

Merlin Mann — Tue, 21 Nov 2006 09:27:21 -0500

Productive Talk #08: GTD 2.0?

43 Folders and The David Allen Company present the eighth in a series of conversations that David and Merlin recently had about Getting Things Done.

Summary

In this episode, Merlin asks David one of the most popular questions about GTD; if he could write the book all over again today, what would he do differently? David addresses how people’s understanding of GTD evolves on repeated exposures, as well hinting at future plans for making GTD easier for people to start and maintain. He makes some great points on learning to pay attention to your “higher altitudes,” and wraps up by underscoring the importance of not having to rethink every task throughout the day. (13:11)

Grab the MP3, learn more at Odeo.com, or just listen here (after the cut).

Merlin’s comments

If you bend David Allen’s ear for more than 30 seconds about GTD, you’ll hear some variation of a phrase that I heard a lot over the couple days we hung out in Ojai: “It’s all in the book!”

Say what you will about The David, but he is not a man who suffers from The George Lucas Complex. Much to the consternation of his publishers, his fans, and — one suspects — even some of his colleagues, David feels like he has already written the complete and definitive work on the Getting Things Done system. And he very clearly has no desire to futz with that basic system without a good reason; it’s sound and complete, as is, and there you go. Next subject.

And, I have to say, in a lot of ways, I’ve come to really admire this.

For one thing, it was immediately clear to me that, although David heads up a smart and growing company that enjoys a ravenous fanbase, his interest in the strictly pecuniary aspects of his work sometimes seems hilariously modest. While he long ago could have flipped DavidCo into a Shake-and-Bake franchise of ghost-written paperbacks (an idea I apparently once thought was a pretty great idea myself), David and his staff usually have more interesting things in mind. And while I can’t say that I think every idea is a guaranteed winner from my own perspective, I really respect the fact that DavidCo seems unwilling to sacrifice the quality of their product and their message for a fast buck. Not something you see every day.

I’ll admit that there’s still a part of me that thinks both David, the fans, and the system itself could benefit greatly from more examples of and options for sane GTD implementation and maintenance (and how to narrow the options to what’s best for my particular hang-up). Funny thing, though: in talking to David, it became clear to me that, on some level, that dearth of “official” material on implementation options was an undeniable factor in the early success of 43 Folders. So, in retrospect, I probably shouldn’t complain too much.

In many ways, though, David’s right; it is all in the book, even if you aren’t yet at a place to understand how it potentially fits together in your world. So, in this episode, I really like how he highlights the way repeated readings and exposures to GTD inevitably lead to “getting” some part of the system that used to seem corny, pointless, or hand-wavey (God knows that’s been true for me). So, I guess I do see part of the challenge from David’s point of view; how do you get somebody quickly ramped-up into a system that may not reveal its best stuff to you for two or more years? Definitely tricky business.

But for those of you out there already doing GTD and feeling like you sometimes miss the “there,” I think this particular ep provides some very sound insight into how these pieces down on “the runway” are inextricably and necessarily tied to “the higher altitudes.”

Last planned episode….but wait…

Although this eighth episode of Productive Talk is our last in this series (yep, we’re already talking about doing it again), I do encourage you to stop back by next week.

In addition to offering my own thoughts on the series and what I learned from it (hint: a lot), I’ll also be sharing the (very very highly requested) single file download of all 8 episodes. Yes, it will have iTunes chapters. No, it won’t have bonus footage or director’s commentary. But it will make it a bit easier to take Productive Talk with you and listen to the whole series at a sitting. Subscribe via iTunes to receive the last last episode as soon as it goes live.

Listen to Episode #08 of Productive Talk

Grab the MP3, learn more at Odeo.com, or just listen from here:

powered by ODEO

”David Allen on GTD's future (and why it just works, as is)” was written by Merlin Mann for 43Folders.com and was originally posted on November 21, 2006. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

David Allen on best practices for implementing GTD

Merlin Mann — Mon, 13 Nov 2006 11:31:34 -0500

Productive Talk #07: Implementing GTD

43 Folders and The David Allen Company present the seventh in a series of conversations that David and Merlin recently had about Getting Things Done.

Summary

In this episode, David and Merlin look at best practices for implementing Getting Things Done. David shares some great advice on firewalling review time and warns us how to avoid the perils of “cruise control.” (9:37)

More at: http://www.davidco.com/ and http://www.43folders.com/

Grab the MP3, learn more at Odeo.com, or just listen here (after the cut).

Merlin’s comments

My favorite bit in this one (jump to 1:38) is where we learn that some of David’s best stuff seems to have had a genesis in an unlikely place — from his tenure as the manager of a gas station, back in the day.

This is important, not just because we get a candid glimpse of a very fun guy who’s too often pegged as just another business consultant — I love that David demonstrates how most any job will benefit from firewalled time to do your meta work.

Note especially that, contrary to what one might call “worst practices” of GTD, DA is not suggesting you spend your day obsessing over GTD and trying to perfect your “system.” You set aside time to clear the decks, as he likes to say, so that you can work — really work — and not just live in a perpetual twilight of productivity futzing.

Building those walls and really honoring them from day one may be one of the best ninja tips you can learn for responsibly implementing GTD.

Listen to Episode #07 of Productive Talk

Grab the MP3, learn more at Odeo.com, or just listen from here:

powered by ODEO

”David Allen on best practices for implementing GTD” was written by Merlin Mann for 43Folders.com and was originally posted on November 13, 2006. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

43f Podcast: David Allen on interruptions

Merlin Mann — Mon, 06 Nov 2006 11:34:19 -0500

Productive Talk #06: Interruptions

43 Folders and The David Allen Company present the sixth in a series of conversations that David and Merlin recently had about Getting Things Done.

Summary

In this episode David and I talked about interruptions. How you can minimize the bad interruptions and make the best of the good ones.

(Running time: 10:17)

Grab the MP3, learn more at Odeo.com, or just listen here (after the cut).

Merlin’s comments

In this episode, David makes the excellent point that if interruptions are a baked-in part of your job, they shouldn’t necessarily be seen as a Bad Thing. It’s just something you need to prepare for by “clearing the decks” in a way that opens you up for the opportunities and game-time input that new information can bring into your world.

Something not to miss — David is just truly a whiz at changing gears based on his own system. If new stuff interrupts what he’s currently working on, he scoops all the current work back into “pending,” and basically says “Bring it on!”

As I mentioned in the interview, watching David work like this took me back to Martin Ternouth’s paper-based system, which turns on a couple key, GTD-esque ideas: 1) you’re only ever working on one thing at a time, and 2) everything current gets emptied and re-evaluated daily.

I think it’s that jog between in-the-moment work and frequent review that really makes a system like GTD work. When (not if) interruptions arise, you trust the system to hold your work in situ, and then your reviews ensure you never miss a beat.

And, finally, although we didn’t get into it as much as I’d like, I really think it’s important to understand and distinguish between interruptions as opposed to distractions. In other words, there are those things that immediately need our attention in life (poopy babies, family emergencies, buildings on fire) versus those notifications, pings, and existential shovelware that we’ve chosen to accept (*waves at RSS feeds and AIM*).

So, if you’re feeling overwhelmed by interruptions, make sure you’ve done everything you can to reduce the noise. In other words, consider clearing your own decks today for the serendipity and kismet that might be coming your way this week.

To paraphrase Thomas Edison, sometimes interesting opportunities arrive dressed as a huge pain in the ass.

Listen to Episode #06 of Productive Talk

Grab the MP3, learn more at Odeo.com, or just listen from here:

powered by ODEO

”43f Podcast: David Allen on interruptions” was written by Merlin Mann for 43Folders.com and was originally posted on November 06, 2006. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

David Allen Interview: Getting Things Done with Email

Merlin Mann — Mon, 30 Oct 2006 08:00:50 -0500

Productive Talk #05: Email

43 Folders and The David Allen Company present the fifth in a series of conversations that David and Merlin recently had about Getting Things Done.

Summary

In this episode, David and Merlin talk about email. We learn that David coaches people to deal with a high volume of messages by treating them like you would any other input.

(Running time: 17:53)

Grab the MP3, learn more at Odeo.com, or just listen here (after the cut).

Merlin’s comments

Email was one of the topics that I was most interested in talking to David about, and I found his responses to my questions thought-provoking.

David makes the case that email is basically just another input — like voice mail, for example — that needs to be emptied and processed every day. That it’s not substantially different (apart from how badly mostly people do it right now).

While I absolutely agree on processing to zero, I think opinions may differ on the significance of email’s impact on the life of the average knowledge worker.

I think David’s approach and advice are tactically quite sound in terms of fixing your own half-acre of the problem, but I’m still ambivalent about a prevailing culture of email in which the implied expectation is that we always need to be on, for example, responding to business-day messages within minutes of their arrival. My friends working down in the Valley (you know who you are) tell me this is the elephant in the room in terms of trying to get anything accomplished between 8 and 6.

While email has matured in terms of adoption, I think we’re still in the very early days of understanding how to use it responsibly across teams and organizations — we’re still a long way from seeing a standard for sound email usage that acknowledges that most “real work” can and should take place outside of an inbox. I really look forward to seeing how we can each help to initiate these conversations in our own circles.

In the mean time, you’ll love hearing David’s advice on Getting Things Done in email. He has a way of cutting to the point that I find really refreshing. Also watch for his prediction on the Blackberry’s inevitable progeny: The Watermelon!

Listen to Episode #05 of Productive Talk

Grab the MP3, learn more at Odeo.com, or just listen from here:

powered by ODEO

”David Allen Interview: Getting Things Done with Email” was written by Merlin Mann for 43Folders.com and was originally posted on October 30, 2006. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

43f interview: David Allen on Getting Things Done with your team

Merlin Mann — Mon, 23 Oct 2006 10:00:33 -0400

Productive Talk #04: Teams

43 Folders and The David Allen Company present the fourth in a series of conversations that David and Merlin recently had about Getting Things Done.

In this episode, David and Merlin talk about the role of GTD in teams and how to lead by example.

(Running time: 08:46)

Grab the MP3, learn more at Odeo.com, or just listen from here:

powered by ODEO

”43f interview: David Allen on Getting Things Done with your team” was written by Merlin Mann for 43Folders.com and was originally posted on October 23, 2006. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

DavidCo's Robert Peake on "Getting Software Done" (part 2)

Merlin Mann — Wed, 18 Oct 2006 08:20:24 -0400

This is the second of a two-part article by Robert Peake, CTO of the David Allen Company. Be sure to start with yesterday’s first part, “Why GTD Matters To Programmers.”

Part II: GTD and Extreme Programming

by Robert Peake, David Allen Company

I have to admit that I’m not a perfect adopter of Extreme Programming. We don’t program in pairs, for example — quite the opposite, our coders are flung far and wide, tethered together only by a broadband connection. However, as much as GTD is “advanced common sense”, so to my mind is Extreme Programming a form of “best practices on steroids” — and for this reason, there are not only many parallels, but great crossover when it comes to managing programming projects.

Software didn’t used to have to be very adaptable. Mainframe software systems were only slightly less mutable than the hardware they ran on, and dependability — not responsiveness, new features, or interoperation with some other cool, new application — was key. Along came the internet, and the ability to patch and change software online. All that changed.

Likewise, while even forty years ago dependability seemed to exist both in terms of job definition and job security, adapting to change may well be the single most important trait of the knowledge worker today. And increasingly, the ability to manage large volumes of information, focusing on what’s important and ignoring the dross, has become key. For this reason, a few critical concepts in programming apply to getting software done with maximum efficiency and also suggest some important directions for any kind of project — they are: regression testing, refactoring, and documentation.

Regression testing is, quite simply, spelling out a list of tests to perform so that you can verify that what you have created works as expected. The “regression” part of it is that you often want to run the same rudimentary tests you ran in the beginning of the project much later in the evolution of the product. This is to make sure you didn’t break something. Regression testing goes hand in hand with documentation, which stems from the same inspiration: describing how the thing should work. Once you have described how the thing should work, and made tests you can perform later to prove it, you need to make sure that documentation exists within the source code. In our case, we use automatic tools to pull out the documentation we mix in with our source code, and have created for ourselves an automatically updated manual of how various functions and parts of our system work. We even set up shortcuts so that with a couple keystrokes, we can access documentation for not only the core language, but our own collection of application-specific functions, right from within the source code we are working on at the moment. The result? Six months after writing something critical, I don’t have to go crawling back through file after file of source code to figure out how to use that particular building block or tool.

All of this relates to GTD when you bring in the concept of outcome-based thinking. Every time you pick up an artifact of your own thinking (be it a scribble on a note-taker wallet page or a mind map on butcher paper) and then decide that what you’ve really notated for yourself is a project, the very next question is: what is the desired outcome? In other words, how will I know I’ve finished this project? What will be the result? Likewise, all the activities in Extreme Programming such as gathering user stories, writing regression tests for each unit and component of the software, and documenting the intended behavior inside the code itself so someone else can later understand what you were trying to do — embody outcome-oriented thinking for software. Jumping to the end first works consistently and well to line up your thinking in the right direction. Getting that thinking captured appropriately into your trusted system — and not over-thinking into all the possible ramifications and rabbit trails that will likely only get blown away when new real-world input arrives — is key to staying agile, flexible, and dynamic.

Another key to programming in an agile way is refactoring. This is going back to what you’ve written — not to add features or fix bugs per se, but to clean up your thinking and make it line up with your new understanding of the project. The truth is that thinking takes time, and it evolves over time. So, revisiting the code on a regular basis, purely for the sake of shoring things up and reworking things into a more effective paradigm, may seem like a lateral shift on the surface — but makes a huge difference in the overall maintainability of the code. Likewise, the maintainability of your life and your trusted system that runs it can also be equated to how often you perform a weekly review. The weekly review is refactoring for life — a time to take stock, reevaluate your understanding of and progress on projects, make sure all actions are tied to projects and projects to actions, and to scrub out all the stuff that’s been either completed or rendered irrelevant by time (sort of like getting rid of the variables you thought you’d need in your code but didn’t — preventing memory leaks and tightening things up for later). Refactoring is as important in life as it is in software.

We used these three branches of Extreme Programming to great success in building GTD Connect. One other critical technique or skill involved was being able to flip from a very high-level creative brainstorming session with our senior people into sussing out the specific outcomes that would demonstrate we’ve done our job on the technology side. None of this precluded writing up documents spelling out our understanding of what’s important and what’s nice to have, the timing involved, as well as some of the mechanics of what we are doing and the business side of how much it would cost. But ultimately, being able to differentiate between and translate from the right-brain mind mapping sessions into left-brain outcomes led to just enough of a specification to get our coders excited. Trusting this process gives you the freedom to be wildly creative in the brainstorming session (because you’re not nailing anything down yet). It also empowers programmers with the flexibility to find a smart, dependable, architecturally sound approach to solving the problem on the other end — because when you feed programmers outcomes rather than dictating precise specifications in pseudo-code, you give them the freedom to work within the context of the whole system to come up with the best solution. And you leave room for constructive, creative surprises — the unexpected killer features that can only thrive in a healthy, outcome-oriented relationship.

One of the tenets of Extreme Programming Merlin mentioned in our panel is the idea that, “You ain’t gonna need it.” While I never overtly said this to The David in our sessions, the spirit of this approach is something that has pervaded the process of leaning into the great (and so far highly successful) experiment of launching Connect. That spirit of the idea is to build to a need, rather than a nice idea. In balance with this, we also tried to cast our net wide enough in terms of variety of features so that we can test and see what people gravitate toward, and what might fall away. This natural process of meeting customer feature demand on its own terms is highly analogous to the GTD approach of getting through each work day on its own terms, using action lists tied to projects rather than other forms of “best laid plans.”

A big key to the mechanics of getting a project as big as Connect done (and then maintaining and improving it incrementally) has been a shared project list accessible by all our developers. First of all, we trust our people. I have never seen the approach of trying to enforce people’s job constraints through software permissions really work when it comes to project management. Instead, anyone can add, edit or mark a project complete in our system. This means that our development people can keep their complete project inventory in a shared format and can edit projects assigned by others to keep notes and add important details. We use a Lotus Notes database for this, but this approach could also be easily implemented via one of many web-based applications or even a shared whiteboard if everyone works in the same room.

Another key with all of this, and a somewhat revolutionary approach, is that we don’t track bugs and feature requests in separate places. It all has to get done anyway. And because maintaining a comprehensive inventory of everything that needs to get done in one place, accessible by all the relevant people, we can very quickly re-calibrate to focus on what’s critical. Sometimes that’s a bug. Sometimes it’s a great new feature. Either way, we use the system to support us like a giant radar screen, and good communication in person, by phone, email, and IM to determine what’s critical and go after it. So far, it’s worked great to keep us engaged with our members and our own staff and be responsive to their input.

Connect has been a lot of fun to build, and it’s great to watch it start to really thrive. Hopefully this little peek under the hood has got your own gears turning about software development with GTD and perhaps even other areas of your work or life where these analogies hold. If you’re feeling particularly geeky, more platform-specific details on the best practices we drew from when pulling Connect together are here.

And if any of this has rung your bell and you want to chat, please drop me a line at robert at davidco dot com, or catch me on the forums. Until next time, happy coding, happy GTD’ing, and be well.

Robert Peake used to teach programming languages to computer science students at Berkeley before earning his degree in poetry. These days he is the CTO of The David Allen Company, where he reads, writes, and thinks about many things in many languages.

Update 2006-10-18 10:05:52 - For your convenience, here’s an easy-to-print HTML version of both of Robert’s posts.

”DavidCo's Robert Peake on "Getting Software Done" (part 2)” was written by Merlin Mann for 43Folders.com and was originally posted on October 18, 2006. Except as noted, it's ©2008 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

David Allen

Business 2.0 interview with GTD's David Allen

Merlin & Leo: Gentle introduction to GTD

HOWTO generate a kGTD Project list for your weekly review

1. Brutal pruning

2. Copy and Paste

Getting your Project List liberated

“WOW, thank you: you’ve taught me to ‘copy and paste.’ So, now what, Admiral Obvious?”

“No, seriously. Why bother?”

Productive Talk Compilation: 8-episode podcast with GTD's David Allen

David Allen on GTD's future (and why it just works, as is)

Summary

Merlin’s comments

Last planned episode….but wait…

Listen to Episode #08 of Productive Talk

David Allen on best practices for implementing GTD

Summary

Merlin’s comments

Listen to Episode #07 of Productive Talk

43f Podcast: David Allen on interruptions

Summary

Merlin’s comments

Listen to Episode #06 of Productive Talk

David Allen Interview: Getting Things Done with Email

Summary

Merlin’s comments

Listen to Episode #05 of Productive Talk

43f interview: David Allen on Getting Things Done with your team

DavidCo's Robert Peake on "Getting Software Done" (part 2)

Part II: GTD and Extreme Programming