Knock Knock. Is there any programmer here?

[TruthWK]

I am a programmer. First, it seems that your main issue was already solved in misunderstanding what goes on a Next Actions list. That being said, for complex programming assignments I would approach things one of two ways.

Option 1 is to put what would be a GTD subproject on the next action list because the next action won't be clear until opening the code and playing around with a few things. Really the next action is a form of brainstorming that involves the code itself perhaps and not a typical mind map or outline. Sometimes putting the subproject on the next actions list is easier than creating a separate action for brainstorming or digging into the code. I often have multiple areas to dig into in my notes for the subproject and I don't want to have to copy those to a next actions list because they can change so quickly. This allows me to be more freeform in my notes and the subproject is actually a better reminder when I comparing it to other things I may want to do in that work context.

Second option is to think of your next action very much like a bookmark. Where did I leave off when I stepped away from this project? The next day or whenever I come back, I may look at things and totally change my mind on what I start on but at least I have that bookmark. Again, I tend to favor option 1 in most cases because sometimes if this next action is too granular it doesn't give me great food for thought in deciding whether to do it vs something else. But there are times when I do use this option if it fits.

 

[Tom_Hagen]

I am a programmer. [...]

It's not entirely that I didn't understand what the next action was. It's more about the nomenclature. For example: many of my projects have a set algorithm. If I buy a product on allegro.pl, my project usually consists of three steps:
* Buy product XYZ on allegro.pl
* Wait for information about the arrival of product XYZ at the parcel locker
* Collect product XYZ from the parcel locker
I use Evernote and I have these three items that I collectively call "Next Actions." The truth is that only one of them at a time is the next action, and that action becomes the title of my Evernote note. The remaining points are really "potential next actions." I got so used to calling them next actions that there was a source of confusion - even though in practice I knew that only one was a next action.
Why do I use this solution? Because it's effective. In obvious projects, I don't have to think about the next step, I can use templates, etc. In less obvious projects, I know more or less how many steps I need to take. Of course, sometimes it is not possible to write out the entire algorithm.

 

[mcogilvie]

For example: many of my projects have a set algorithm. If I buy a product on allegro.pl, my project usually consists of three steps:
* Buy product XYZ on allegro.pl
* Wait for information about the arrival of product XYZ at the parcel locker
* Collect product XYZ from the parcel locker

In situations like this, with short sequential steps, I will sometime just edit a single entry so it reads “Order xyz” then “WF xyz” et cetera, Other times I will duplicate and edit, or I will use a format like “Problem Set 2 solutions: prep, post, print” and delete verbs as I go. It’s surely a matter for personal preference and the list tool used.

 

[Tom_Hagen]

In situations like this, [...]

I paste the next action to the title and move the note to another notebook that provides context for me.

 

[Matt_M]

Responding to the original question:

As a professional software engineer, let's remember GTD is for managing an individual's tasks. GTD is not project management. It's not for managing professional software development, multi-phase construction projects, designing intricate real-world systems, producing a movie, launching a rocket ship, etc.

Put simply, GTD is the wrong tool for those kinds of endeavors. Instead, use tools like agile (i.e. Scrum, Kanban, XP, etc.), waterfall, traditional project management, etc. Supplement it with complimentary best practices such as FDD (feature-driven development), user stories, Kaizan principles (i.e. CI/CD, DevSecOps), etc.

I don't use GTD for either my professional software development work or for my personal programming projects. It doesn't work for those kinds of activities much like how a screwdriver doesn't work to cut a plank in half.

Considering this not a forum for software development, I won't ramble on about the aforementioned topics but instead point folks to research those separately.

 

[Tom_Hagen]

Responding to the original question:
[...]

Yes and no. I agree that GTD will not replace all supporting systems. Of course, when managing projects, we will need a Gantt chart, milestones, etc. When writing software, we use SCRUM, Agile or something similar. Just note that these systems fall under the category of supportive materials / systems. This means that in the GTD methodology they require regular review and generate appropriate obligations. If the project consists of milestones, according to GTD there is no reason why the dates of these milestones should not be recorded in the calendar. If a given project consists of appropriate steps, there is no reason not to record them as next actions. If a given stage of the project is carried out by someone else, there is no reason not to record it on the list of delegated matters, etc.
I know what I'm writing about because I'm currently implementing a very large programming project and I use both supporting materials and the GTD system.

 

[TesTeq]

This means that in the GTD methodology they require regular review and generate appropriate obligations. If the project consists of milestones, according to GTD there is no reason why the dates of these milestones should not be recorded in the calendar. If a given project consists of appropriate steps, there is no reason not to record them as next actions. If a given stage of the project is carried out by someone else, there is no reason not to record it on the list of delegated matters, etc.

@Tom_Hagen I agree that I should review regularly the company's project that I take part in . But if there's some kind of company-wide project management software I see no purpose in copying deadlines, actions and delegated stuff to my personal GTD system.

 

[Tom_Hagen]

@Tom_Hagen I agree that I should review regularly the company's project that I take part in . But if there's some kind of company-wide project management software I see no purpose in copying deadlines, actions and delegated stuff to my personal GTD system.

Okay, but are we still talking about conducting professional projects in the GTD methodology or rather about separating GTD systems into two areas: personal and professional. Because these are two separate issues.

 

[Y_Lherieau]

My understanding is that the second action there is not a next action because you cannot do it next. It might be a future action, but the very next thing you need to do is make a phone call.

I would:

• Put "call the mechanic" on my next actions list.
• Consider putting "go to mechanic" in my project support, although for this simple project I might not have any project support at all. In fact, in this example, I would imagine that "go to the mechanic" would never end up on my actions list. Either the mechanic will tell me to bring the car right now, in which case it is work done as it shows up, or they will give me an appointment which I would put on my calendar.

---

I've appreciated reading everyone's insights and strategies on managing "next actions" within our projects. I'd like to share my approach, which has been tailored through my use of Todoist, specifically leveraging its board view to align with GTD principles effectively.

In my Todoist setup, I've dedicated the first project column of my board view to distinctly capture the 'Purpose', 'Desired Outcome / Results', and 'Next Action' for each project. This strict segregation ensures that I always have a clear and actionable next action identified, which is pivotal in maintaining momentum on my projects. This column is my commitment to focusing solely on immediate action; anything listed here is ready to be acted upon without any further planning required.

Recognizing the importance of not losing sight of future tasks while also adhering to the GTD tenet of keeping the next actions list uncluttered, I've innovated a solution that accommodates both needs. I've established a second column on my board, which serves as a backlog spot.
This space is invaluable for capturing potential future actions as they occur to me during my project reflection sessions. It's a strategic reserve of tasks that I might need to act on once the current next action is completed.

This system allows me to "park" these thoughts and tasks without losing them or letting them distract me from my immediate next action. When I complete a task in the 'Next Action' column, I then review the backlog to reassess and decide which task is the new immediate next action, transferring it to the first column. This not only ensures that I'm always working on the most critical task at any given moment but also that I'm efficiently planning ahead without cluttering my immediate workspace with tasks that cannot yet be actioned.

This approach has been instrumental in helping me maintain focus, reduce overwhelm, and ensure that no potential action falls through the cracks. By leveraging Todoist's board view in this manner, I've found a practical and effective way to implement GTD's principles, tailor-made to my workflow and cognitive style.

 

[bishblaize]

Responding to the original question:

As a professional software engineer, let's remember GTD is for managing an individual's tasks. GTD is not project management. It's not for managing professional software development, multi-phase construction projects, designing intricate real-world systems, producing a movie, launching a rocket ship, etc.

Put simply, GTD is the wrong tool for those kinds of endeavors. Instead, use tools like agile (i.e. Scrum, Kanban, XP, etc.), waterfall, traditional project management, etc. Supplement it with complimentary best practices such as FDD (feature-driven development), user stories, Kaizan principles (i.e. CI/CD, DevSecOps), etc.

I don't use GTD for either my professional software development work or for my personal programming projects. It doesn't work for those kinds of activities much like how a screwdriver doesn't work to cut a plank in half.

Considering this not a forum for software development, I won't ramble on about the aforementioned topics but instead point folks to research those separately.

This is what my friend concluded. Its not that you cannot combine GTD with other supporting tools. Rather that paradigm of Projects and NAs wasn't sufficient to track his workload in a useful way.

I think a lot of GTDers already use support tools for their projects, anything from a simple handwritten note up to a kanban board or Gannt. But if you reach the point where 90% of your work is in the support tool, then its valid to ask whether its not a support tool, but actually your main tool. And to query what added value GTD is adding at that point, given the additional work to manage it.

I know in his case they use Jira Boards, which not only acts as a project management tool but also allow his team to communicate with each other and the client on an task by task basis. So they just live of that.

Of course, there's a question about whether GTD is as specific as the structure of Projects and Next Actions, or whether its about the more generalised behaviour, like making decisions on the front end, inbox zero, all that stuff.

 

[Tom_Hagen]

Of course, there's a question about whether GTD is as specific as the structure of Projects and Next Actions, or whether its about the more generalised behaviour, like making decisions on the front end, inbox zero, all that stuff.

Of course, GTD is not limited to the set: Projects + Next actions. GTD covers a much, much larger area, including: reference or supporting materials, focusing horizons, the natural planning model, etc. For example, Allen wrote in his book that there were weeks when he did not work on the next actions list because he was so busy with the things on his calendar that he did not have time for them. Does this mean that he dropped out of GTD because the calendar became his main tool? Of course not. The calendar is a component of the entire GTD methodology. Similarly, your friend - if most of the work is based on JIRA, it only means that JIRA has become part of his next action lists.

 

[Matt_M]

Without going off-topic, repeating prior notes/rambling on about software development, or rehashing what folks have already said in more, different ways; I will simply say that the issue here is that GTD is the wrong tool for the job.

When we have to/try to "force" a tool/model/methodology to fit a problem, it's the canary in the coal mine that we're using the wrong one.

Agile, waterfall, traditional project management, etc. are the methodologies that work for the job here. Even David Allen has stated this in all but the same words in various interviews and podcasts. GTD is complimentary practice at best and could dovetail but cannot compete, replace, or supplement the correct aforementioned methodologies.

 

[Tom_Hagen]

Without going off-topic, [...]

I do not agree with this opinion. If we take Jira into account - then, as I said - it is nothing more than a list of next actions with an already defined context (most likely "at computer" - although not always, you may need to discuss something with somebody; the context may also be the application to which the tickets concern ). If we take SCRUM into account, there will be elements related to the calendar: such as a team meeting and another list of next activities, and in the case of the team leader - on the delegated list. Gantt will be a set of deadlines (milestones) and a source of detailed commitments. Etc. etc. And unless your life is limited to one or two projects (and I don't think it is), you will be accompanied by a whole host of other obligations, ranging from trivial ones such as replacing the battery in the remote control to more complex ones. How JIRA / Agile / Scrum and what else will allow you to control this entire inventory? How will you know whether to spend the evening relaxing or maybe you need to catch up on a project? How will you know if what you are not doing will not generate a fire in the future? How will you even know if what you are doing at a given moment is the right thing? Unless someone is an anchorite, it's hard for me to imagine why keeping everything in your head or ignoring potentially dangerous obligations would serve you well.

 

[RomanS]

For me, methods and tools such as Gantt, Agile, Scrum, etc. are alternatives for the natural planning model (vertical project control). However, they still require horizontal control in the form of next actions.

 

[mcogilvie]

For me, methods and tools such as Gantt, Agile, Scrum, etc. are alternatives for the natural planning model (vertical project control). However, they still require horizontal control in the form of next actions.

Kind of, yeah. I’m not sure they are alternatives so much as elaborations downstream of it. A Gantt chart is not going to replace the elevator pitch on the back of a napkin. The person with the vision of the project still needs the natural planning model or something like it.

 

[Matt_M]

I do not agree with this opinion. If we take Jira into account - then, as I said - it is nothing more than a list of next actions with an already defined context (most likely "at computer" - although not always, you may need to discuss something with somebody; the context may also be the application to which the tickets concern ). If we take SCRUM into account, there will be elements related to the calendar: such as a team meeting and another list of next activities, and in the case of the team leader - on the delegated list. Gantt will be a set of deadlines (milestones) and a source of detailed commitments. Etc. etc. And unless your life is limited to one or two projects (and I don't think it is), you will be accompanied by a whole host of other obligations, ranging from trivial ones such as replacing the battery in the remote control to more complex ones. How JIRA / Agile / Scrum and what else will allow you to control this entire inventory? How will you know whether to spend the evening relaxing or maybe you need to catch up on a project? How will you know if what you are not doing will not generate a fire in the future? How will you even know if what you are doing at a given moment is the right thing? Unless someone is an anchorite, it's hard for me to imagine why keeping everything in your head or ignoring potentially dangerous obligations would serve you well.

It seems like we're conflating personal tasks with professional software development vis-a-vis project management. Going to the dentist, taking Timmy to soccer, and filing my taxes are all things I have in my personal system. Those are the exact things GTD is designed for.

Writing software, completing user stories, and prioritizing a backlog based on user feedback loops is precisely the things GTD is not for. The original question was about how to use GTD to develop software therefore my focus in my responses.

You mentioned items like sprint ceremonies, team meetings, and so forth. Yes, these are indeed calendar events. Beyond that, I am not sure what exactly we are tracking here. Those kinds of events are setup just one time as recurring meetings forever (or thereabouts). There's nothing special about them. There's nothing to track for delegation or such, since they're highly structured events with pre-determined agendas, processes, practices, tools, and so forth.

Ad-hoc meetings are usually either for clarification on details or for creating work to go into the backlog/sprint (circumstances depending) to be prioritized in the next sprint planning meeting. Ceremonies follow the later anyways.

Regarding how to spend an evening, weekend, holiday, and so on: simple, I have hard boundaries. I stop working at 5 PM. Anything after that is not my problem until the next business day unless someone's paying me to care in the meantime (and believe me, people don't like my rates after 5 PM and only the most troubled of teams/products will pay).

As for "How will you know if what if what you are not doing will not[or could] generate a fire in the future?", again, I am not trying to be flippant but simply put: I don't and so what? Nobody can predicate the future and we can spend all day catastrophizing playing out infinite "What if ..." scenarios. The reality is, stuff happens and we roll with the punches.

I can either spend all of my time worrying about what could happen or I can just live life, move on, and take things as they come. I chose the later.

That's not to say good planning, sound policies, and reasonable controls don't help, they most certainly do but life is short. I don't plan on dying at my desk thinking "If I just worked a little bit more, planned a little better, or spent more time at the office ... "

 

[Tom_Hagen]

It seems like we're conflating personal tasks with professional software development vis-a-vis project management. Going to the dentist, taking Timmy to soccer, and filing my taxes are all things I have in my personal system. Those are the exact things GTD is designed for.

Writing software, completing user stories, and prioritizing a backlog based on user feedback loops is precisely the things GTD is not for. The original question was about how to use GTD to develop software therefore my focus in my responses.

You mentioned items [...]

The starting point of the discussion with you was your thesis that GTD is not very suitable for IT projects. Meanwhile, what you write about rather concerns the adopted model or lifestyle. And I can understand that. It is a matter of personal choice, not to mention taste. And as we know, "de gustibus non disputandum est". If your professional life is limited to specific hours with clearly defined obligations (perhaps very uniform like Jira submissions), if life is so simple (that's not an objection) that you can keep your current obligations on a short list or even in your head - that's fine. GTD is a methodology for people, and the vast majority of them are, who receive a constant stream of information that requires processing either into something that requires some action or at least into something that requires archiving. I don't have that comfort. My work as an IT specialist almost always consists of several dozen projects with different time horizons, requiring constant supervision and selection in terms of priority and deadline. My personal life is also full of many obligations, partly external and partly internal, which allows me to direct my development and plan it consciously. In my opinion, spontaneity is good for one-off things, but not for something that is a long-term, complex process.

 

[RomanS]

In my opinion, spontaneity is good for one-off things, but not for something that is a long-term, complex process.

Only GTD makes real spontaneity possible for me. Because only when I know what I'm not doing (or don't want to do) can I calmly embrace the spontaneous alternative. Without clarity about all my commitments (whether professional or private), the tasks would control me, not me controlling the tasks. I would simply do what screams loudest at the moment. I don't see that as true spontaneity.

Translated with DeepL.com (free version)

 

[RomanS]

It seems like we're conflating personal tasks with professional software development vis-a-vis project management. [...]

GTD does not differentiate between professional and private obligations. Commitments are simply commitments, regardless of whether they arise from the Gantt plan of a professional project or a defective tire on a personal car. - I have to manage them both.

I don't plan on dying at my desk thinking "If I just worked a little bit more, planned a little better, or spent more time at the office ... "

For planning, I only use GTD to gain vertical control so that I can get stuff out of my mind (whether professionally or privately). The rule is: as little as possible, as much as necessary.

 

[bishblaize]

Of course, GTD is not limited to the set: Projects + Next actions. GTD covers a much, much larger area, including: reference or supporting materials, focusing horizons, the natural planning model, etc. For example, Allen wrote in his book that there were weeks when he did not work on the next actions list because he was so busy with the things on his calendar that he did not have time for them. Does this mean that he dropped out of GTD because the calendar became his main tool? Of course not. The calendar is a component of the entire GTD methodology. Similarly, your friend - if most of the work is based on JIRA, it only means that JIRA has become part of his next action lists.

I think we need to avoid Maslow's hammer here. If he's not using the distinction of Projects and NAs, or looking at things with the six horizons, then I think it starts to become tenuous to argue that it follows GTD principles. Via that logic you could argue that a daily ABC to-do list is actually GTD, despite them being described by David Allen as antithetical to GTD.