Computer Programmers using GTD?

[iTISTIC]

Was wondering if there are any developers on this board that have implemented the GTD system in their lives? I, personally, am finding it to be a bit difficult.

The main problem I have is that I must plan out an entire project at the beginning, and then schedule the entire project on my calendar, and create next actions for the same events I have placed on the calendar. I cannot simply take one action during the week and wait until the weekly review to decide on the next action to be taken the following week. Doing things this way will cause projects to take forever to be completed. Instead I think a Daily review would be best, but even doing this Daily the same problem exists.

Just curious as to how other developers implement GTD and are able to provide timelines to their clients and stick to proposed deadlines?

 

[Jeff K]

next action = a bookmark

I see this similar sentiment about the GTD methodology all the time - that only one next action per project is allowed, which is not updated until the next weekly review.

A better way to understand a next action is that it is like a bookmark in a project - once you complete it, if you like, you can stay in the flow of that project, and keep working on the next action, and then the next action..... Some people then get to a point where they record the next action to do on their list, for the next time they are able to pick up that project again.

the intention of GTD is NOT to limit you to one action per project per week, but to give you the most efficient way to know exactly what your next starting point is for every given project.

If you work with firm deadlines, than you need to have appropriate days or hours marked on your calendar to complete the required project steps by set times.

also, you can search through this forum for description of "pigpog" method.

 

[iTISTIC]

A better way to understand a next action is that it is like a bookmark in a project - once you complete it, if you like, you can stay in the flow of that project, and keep working on the next action, and then the next action..... Some people then get to a point where they record the next action to do on their list, for the next time they are able to pick up that project again.

This is a good idea. I will still have to completely plan all actions required of the project before I begin the project, but I can always complete an action and decide I want to conitnue working on the project, and just grab the next action off of the project's list and go from there. I just have to be sure that when I complete working on that project for that session that I create a new Next Action to keep the project in my NA lists. Doing this will also make the weekly review a little easier as I should already have appropriate NAs for each project listed that I worked on during that particular week.

 

[flexiblefine]

Where did this idea come from?

I see this similar sentiment about the GTD methodology all the time - that only one next action per project is allowed, which is not updated until the next weekly review.

Where does this idea that we can only update next actions at the Weekly Review come from? If we believe that, then we believe that even the simplest project (since it requires more than one action) requires more than one week to complete.

Jeff is right -- the "review" part of the five-step process is supposed to take place much more often than weekly. We're supposed to review our lists whenever we're not doing something, so we can find the next "something" to do. When a next action is finished, if you know what the next next action is, treat it like any newly-decided action -- do, defer, or delegate.

We can and should add new next actions to our lists whenever they come to mind -- the Weekly Review is about reviewing the whole system to make sure we aren't missing anything in our smaller, more frequent reviews.

 

[Tetsujin]

Next Actions

I too wonder why people think they can only update their Next Action lists at the Weekly Review. Also, why do people think that a project can have only one Next Action?

For the project "clean garage" I might have an action "Buy new Shop-Vac" and another action "Call Doug about the old dresser he wanted" I can do either of these without precondition, so they'd both go on my Next Action lists -- one on @Errands, and the other on @Phone. Why arbitrarily limit myself to one or the other? Context, energy, etc. will help me decide which to do when.

The only actions for a project that don't immediately go on a context action list are those for which something else has to happen first before I can take the action. For example, "Vacuum under work bench" would have to wait until "Buy new Shop-Vac" is completed.

-T.

 

[iTISTIC]

I too wonder why people think they can only update their Next Action lists at the Weekly Review. Also, why do people think that a project can have only one Next Action?

For the project "clean garage" I might have an action "Buy new Shop-Vac" and another action "Call Doug about the old dresser he wanted" I can do either of these without precondition, so they'd both go on my Next Action lists -- one on @Errands, and the other on @Phone. Why arbitrarily limit myself to one or the other? Context, energy, etc. will help me decide which to do when.

The only actions for a project that don't immediately go on a context action list are those for which something else has to happen first before I can take the action. For example, "Vacuum under work bench" would have to wait until "Buy new Shop-Vac" is completed.

-T.

This is a very good point. With programming work, however, typically each action has some sort of prerequisite before it can be completed. There are items, however, there are projects that will contain items which are not order specific. The problem lies in the fact that if there are many of these non order-specific actions belonging to a project that we will then have Next Actions lists that are full of items that belong to one project, which can become a bit cumbersome. I guess if this were the case you could segment the project and say "Ok, I'm going to take care of these few items first, then these, etc etc etc".

 

[Suziloo]

Having hard time implementing GTD

I am a programmer, bought GTD last year and made some faint-hearted attempts to apply (paper, palm)... until now. Now I'm using Life Balance to manage my next actions. I'm not so much interested in balancing my life (that'll come after i have work under control), but in managing my workflow.

What I like about LB is that you have some flexibility in your planning. You can set up NAs sequentially, or by due date or by calendar (all with lead times that you can adjust). The To Do List does a pretty good job of prioritizing your NAs as long as you set them up properly. If you've completed all the NAs for a project, the project itself will appear on your to-do list to remind you that you need to do some more planning/assigning.

The bad thing about LB... It takes some getting used to to set up your next actions properly and can be cumbersome. If you have tons of NAs, it can become unweildy.

You can also assign when certain contexts (places) are open or closed. So my @office is only open 8-5 on weekdays and home is all other times (I have a home office so I'm trying to put some boundaries on my time). If I want to work at night or on weekends, I have to click a checkbox to 'include closed places', which is a good reminder that I'm not getting enough done during the workday & I need to work more efficiently. I'm trying to break my "later/tomorrow" habit so that feature is a good one for me.

I gave up trying to find the "perfect" software for implementing GTD. LB has its quirks & limitations, but it's good enough for me. Thought about creating my own system, but that would just add to my projects/NAs and I'm not willing to do that at this time.

I've got myself on a daily review schedule until I can feel comfortable that my weekly review & inbox processing are strong enough to cut back. It's been hard to go from listing projects to listing NAs. I used Franklin for about 15 years and their recent store closing in my area was the best thing that happened to my productivity. The system wasn't working for me (or I wasn't working the system), but I didn't reassess my options until I went to buy refills and the store was no longer there.

HTH

 

[cyberscribe]

Get Agile

The main problem I have is that I must plan out an entire project at the beginning, and then schedule the entire project on my calendar, and create next actions for the same events I have placed on the calendar. I cannot simply take one action during the week and wait until the weekly review to decide on the next action to be taken the following week. Doing things this way will cause projects to take forever to be completed. Instead I think a Daily review would be best, but even doing this Daily the same problem exists.

I have two points of feedback on this problem.

First, you seem to be taking the methodology too literally. It is not a hard and fast algorithm that says assign next actions weekly and only weekly. It is a methodology that accounts for real-world ambiguity in project planning and puts you in control at every point of the decision making process by providing a complete inventory of your open loops. In programming terms, you can think of it as a kind of breadth-first search. Once you have that first tier of breadth, you have placed everything you are not working on that you could be working on into a trusted system and can therefore devote your full resources and attention to the task at hand.

Once that task is complete it may very well be that the next thing to do is the next logical step to make progress on the same project (i.e. go for some depth). In which case, if it's two minutes or less you do it without incurring the overhead of putting it in your organizational system, and if not, you put it in the system so that when (not if) you get interrupted, you can reevaluate based on new information and return to tackling the most important next action (whether or not it's the same action you thought it would be before the interruption). The freedom to be able to focus confidently on the next task at hand when tackling a complex coding project, and the power of being able to respond to real-world variables without having to overhaul major project plans are some of the greatest gifts GTD gives to coders.

My second point is that your software projects don't read your project plan. They don't know how they're "supposed" to evolve, and given variables like unforseen technical challenges, clients who change their minds, and everything else under the sun that plagues projects and pushes out their best laid plans, I couldn't think of a better project execution methodology than GTD. It is certainly not a substitute for good planning and foresight (i.e. lay those plans anyway), but combined with a more agile methods approach, it lets you tackle projects in a more "real" way than any of the traditional project planning methods, which try to encompass the scope and complexity of a project entirely on the front end. In the software development world, projects like that often go obsolete before anyone ever actually writes a line of code.

That's been my experience with GTD in the software game. Hope that helps somehow.

Cheers,
Robert

 

[ceehjay]

Ah, Mr. Peake, you may be talking the software game, but your words fit other games, too. Such wisdom!

Interruptions, changes, scrap this project, start that one. As the top bosses at my workplace say, "Truth is a moving target."

Carolyn

 

[cyberscribe]

Thanks, Carolyn. The wisdom is borrowed by the experience is my own. I only take credit for being lucky, smart and persistent enough to try this stuff out and discover how remarkably well it works in my own little corner of the world. Couldn't help but respond to this one, since that corner happens to involve a lot of software development.

 

[Brent]

I will still have to completely plan all actions required of the project before I begin the project

Why is that?

 

[iTISTIC]

Why is that?

Because clients request timelines and project completion dates, etc. which require me to plan the entire project and estimate to my best ability how long each phase of the development will take. I then have to schedule these phases so they are completed by these deadlines.

 

[kewms]

Because clients request timelines and project completion dates, etc. which require me to plan the entire project and estimate to my best ability how long each phase of the development will take. I then have to schedule these phases so they are completed by these deadlines.

I'll bet you don't plan *every* action associated with the project in advance. Most of your planning is probably more at the GTD subproject level.

From a GTD perspective, the risk lies in thinking that your formal project plan is all the planning you need to do. This tends to result in "next action" items that are really "stuff" in disguise. For example, how many discrete actions actually go into "outline menu structure" or "design database schema?" How many of those appear in your master project plan?

Katherine

 

[iTISTIC]

I'll bet you don't plan *every* action associated with the project in advance. Most of your planning is probably more at the GTD subproject level.

From a GTD perspective, the risk lies in thinking that your formal project plan is all the planning you need to do. This tends to result in "next action" items that are really "stuff" in disguise. For example, how many discrete actions actually go into "outline menu structure" or "design database schema?" How many of those appear in your master project plan?

Katherine

I see exactly what you're saying, and you are right, things such as "Design Database Schema" are typically in my NA lists. In fact there is one there now entitled the same for a project I am working on. I do feel, however, that this NA is a valid one. You could get more granular by having a NA for the creation of each database object, the details of each object, etc. but the amount of NAs you'd have to have would be way too many to manage. What would you suggest instead of "Design Database Schema"?

 

[kewms]

I see exactly what you're saying, and you are right, things such as "Design Database Schema" are typically in my NA lists. In fact there is one there now entitled the same for a project I am working on. I do feel, however, that this NA is a valid one. You could get more granular by having a NA for the creation of each database object, the details of each object, etc. but the amount of NAs you'd have to have would be way too many to manage. What would you suggest instead of "Design Database Schema"?

What level of granularity makes sense to you? I don't have to use your plan.

One way to approach it might be to plan your NAs around the amount of work you can do in one sitting, say 1-2 hours of work. You might be able to design a complete name and address database in that amount of time, but only a small piece of an image database. Either way, the goal is to have NAs that are granular enough to clearly answer the question "what do I do next?"

As for having too many NAs to manage, I would say that's what software tools are for. If there are too many NAs to manage on paper or electronically, then there are *way* too many to keep in your head. Write them all down, then use dates, categories, and other filtering tools to hide the ones you don't need to worry about right now.

Katherine

 

[cyberscribe]

Subproject: Design Database Schema

Project: Deploy Stable Release Of Killer App
Subproject: Design Database Schmea
Next Action: Sketch rough draft of table relationships

after that is done, possible subprojects and next actions might include:

Subproject: Run draft schema by the rest of the development team
Next Action: Email x y and z to set up a time to go over the design schema

Subproject: Normalize the rough draft schema
Next Action: ask coding partner x to look for unnecessary data duplication in draft schema

I'm making all this up, but you get the idea. Activities in development don't always follow the programming structure of a project -- meaning, each design object is not necessarily a next action. The real-world process often has nothing to do with objects or data structures and much more to do with approvals, lines of communication, people's schedules, unforseen bugs, added features, last-minute requests from marketing for a summary of features, and of course reports with TPS cover sheets on them. Right?

 

[gnugrep]

I'm a programmer and I've been using GTD for over a month now. I'm still refining my process, but this is how it is so far. Basically what I do is plan out the projects beforehand in Word. Once I finish with this, I look over the plan and figure out what the next action is and put it on my NA list. When I get to that item in the next action list, I pull the supporting file and open up the project plan and begin work. What I usually do then, is finish the task that was on my NA list, then I look at the project plan and figure out the next action and then just do it. I usually do a number of next actions all at once. They never actually get on a list, because I'm working on this particular project for 2 hours and it is just faster to do it than create a list item. When I feel like I've had enough of this particular project, I figure out the next action, put it on my NA list and close the files and move to something else. This way the NA is kind of like a bookmark for this project.

Another thing I've found is that as I'm coding, I figure out there is some task that isn't on my list, if it is the next thing to do, I just do it, without putting it on a list. I think the idea is that once you are on a roll, just keep working on the project without stopping to put an item on your next action list and then doing the item and crossing it off the list. Then you are creating extra work for yourself without any benefit.

 

[iTISTIC]

I'm a programmer and I've been using GTD for over a month now. I'm still refining my process, but this is how it is so far. Basically what I do is plan out the projects beforehand in Word. Once I finish with this, I look over the plan and figure out what the next action is and put it on my NA list. When I get to that item in the next action list, I pull the supporting file and open up the project plan and begin work. What I usually do then, is finish the task that was on my NA list, then I look at the project plan and figure out the next action and then just do it. I usually do a number of next actions all at once. They never actually get on a list, because I'm working on this particular project for 2 hours and it is just faster to do it than create a list item. When I feel like I've had enough of this particular project, I figure out the next action, put it on my NA list and close the files and move to something else. This way the NA is kind of like a bookmark for this project.

Another thing I've found is that as I'm coding, I figure out there is some task that isn't on my list, if it is the next thing to do, I just do it, without putting it on a list. I think the idea is that once you are on a roll, just keep working on the project without stopping to put an item on your next action list and then doing the item and crossing it off the list. Then you are creating extra work for yourself without any benefit.

As a fellow developer I totally agree with this process. The process is the same for me. I have a detailed proposal for each development project I work on, and go through this same process. Good points and explanation.