Task switiching (not necessarily context)

Discussion in 'PUBLIC: Discuss the GTD Methodology' started by Tom_Hagen, Feb 13, 2019.

  1. Tom_Hagen

    Tom_Hagen Registered

    Joined:
    Feb 23, 2018
    Messages:
    25
    Likes Received:
    14
    Trophy Points:
    3
    Gender:
    Male
    As we know the core of GTD are next actions. These are the nearest, physical actions that can be done asap considering context, time, energy i priority. Concerning granularity lots of people recommend "size" which allows done task in one sitting. This seems to be reasonable because there are lots of projects which are big and tedious. So everyday one can complete several such a tasks until projects are done. Allen if I am right calls it "fooling yourself". In opposition to this SCRUM emphasizes the need to implement one project at the same time arguing that switching task involves mental and time costs. According to this if you have several hours of free time you should be doing one project even if next action is really big. It also seems reasonable. Of course big next action may cause discouragement and lead to procrastination. What is your opinion? Shall we "foolish ourselves", divide big projects into small steps, switching tasks even for the price of efficiency or shall we stick to project and try to force ourselves to complete big tasks?
     
  2. Oogiem

    Oogiem Registered

    Joined:
    Jun 3, 2008
    Messages:
    4,593
    Likes Received:
    402
    Trophy Points:
    83
    Gender:
    Female
    First off I disagree that it is fooling ourselves to divide big projects into small steps.

    The answer whether to divide projects or not is It depends. Some people need the small granularity and some don't. Some projects lend themselves to splitting and some don't.

    What is key is consider the cost of both task switching and the cost of task focus. There are costs and benefits to both approaches and you may need to use both of them at different times on the same project or on different projects.

    personally, I tend to split tasks into logical discrete steps that stay in a context. I have had individual next actions that took several months or even years to complete but it was still the next logical step in the project.

    On occasions I have also taken big huge long tasks and split them up so that my next action was "Work for 30 minutes on X" because I needed that small time focus to move the project forward.

    Also, for me, I can switch projects faster and with less mental effort and time wasted compared to the cost to switch contexts. I'd rather stay in a context until it doesn't make sense working on actions from that context rather than start on a project and then just continue in that project switching contexts willy nilly as the actions come up.
     
    Tom_Hagen likes this.
  3. Longstreet

    Longstreet Registered

    Joined:
    Sep 11, 2002
    Messages:
    1,157
    Likes Received:
    396
    Trophy Points:
    83
    Gender:
    Male
    Occupation:
    Professor of Microbiology & Infectious Diseases
    Location:
    University of Iowa
    Think of a next action for a major project as a bookmark. It is to help you get the ball rolling. Once you have completed it and need to do focused, deep work on that major project, keep going. Block time on your calendar for this focused, deep work. When your time block is done and there is still more to do on that project, then do not leave the time block until you have identified the next action. This next action will be your new bookmark.

    Don't worry about context switching here in this deep work. Just focus on the project and move forward!
     
    Tom_Hagen and TesTeq like this.
  4. Gardener

    Gardener Registered

    Joined:
    Sep 11, 2008
    Messages:
    742
    Likes Received:
    89
    Trophy Points:
    28
    I don't see that you have to choose one or the other.

    It seems reasonable to stick with one project, pre-organize its large tasks into smaller steps, and then just keep on working on those smaller steps without switching away from the project. As long as you're inside the project, you're reducing the cost of the task switching.

    For example, I'm still working on that novel. It's about three-quarters done but it has too many loose ends. Right now, I'm going through the manuscript so far, existing-chapter by existing-chapter, cleaning up continuity errors and fixing holes and writing missing scenes.

    I could call this all one task ("Get the manuscript so far to near-first-draft quality.")
    I could divide it into chapters. ("Clean up first chapter." "Clean up second chapter.")
    I could divide it into scenes. ("Clean up first scene of first chapter.")
    I could just take it bite by bite. ("Size the next bite. Clean it up.")

    I'm doing the last--not that I'm phrasing it that way, but I am thinking of it in units that allow me to periodically experience "finished". I just finished the bonfire scene. I'll write--thus "finish"--a piece of glue between the previous scene and the bonfire scene. That will mean I've finished the fourth chapter. Yay!

    So I experience those as individual tasks with the satisfaction of finishing, but all the while, my mind is "inside" the novel--I don't have to dump the whole thing and switch my thoughts to a different personal projects. I do of course have to dump my thoughts every day and switch my thoughts to work, but, well, paychecks are good. But at work I can still try really hard to stay "inside" one project as long as I can.
     
    Tom_Hagen likes this.
  5. John Ismyname

    John Ismyname Registered

    Joined:
    Dec 29, 2017
    Messages:
    121
    Likes Received:
    31
    Trophy Points:
    28
    Gender:
    Male
    I do not see a contradiction here. A project consists of a collection of tasks. I'm a believer in sub-dividing these tasks into what can be accomplished in ideally "one sitting" or, at the very least, a single work day. At best, projects get behind schedule when there is not this daily progress. At worst, a workday goes past where nothing is done on it, and the project 'gathers dust' as nuances are forgotten. When this happens, the project is going "in reverse".

    SCRUM addresses this with the sprint concept - the project team drops everything else and focuses on their tasks at hand for the sprint session and then does other thing until the next sprint session.

    The former is a continuous marathon. The latter are broken-up sprints. Neither is right nor wrong, the best methodology depends on the project, the team members, and the comfort with the methodology.
     
    Tom_Hagen likes this.

Share This Page