Serial Mono-tasking In Action
Part Two of The Case Against Multitaking.
By Thomas M. Cagley Jr.
Audio Version of Part One
Audio Version of Part Two
Recap of Part One: True multitasking in the work place is rare at best. Even when we think of fast-switching as a form of multitasking, multitasking lacks efficiency due to switching costs. If you decide to accept the cost of multitasking, the act of multitasking is — complicated. Complexity causes errors and makes more work which reduces effectiveness even more.
Serial mono-tasking with planning is a mechanism that can help minimize switching costs and complexity. As noted in Part One of the essay, mono-tasking makes the most sense if efficiency and productivity are your goals. How we implement mono-tasking in the face of an interrupt-driven world is an open question.
Serial Mono-tasking In Action
I would suggest that any approach to dealing with tasks whether for a program, project or a personal to-do list must be based on a process that includes specific coping mechanisms.
Prioritization: As noted in “The Case Against Multitasking”, having a few tasks queued up reduces switching time. Switching time is the time required for the person doing work to prepare to do the next task based on a new set of rules. As an example of these different rules, consider the rules and constraints you have in mind when writing an email to your significant other; now consider the constraints and rules you would have to keep in mind if writing an email to your boss (unless they are the same). Another example of a task with different rules would be coding a user-facing website as compared to loading a data warehouse table. Prioritizing tasks can serve three purposes: The first is to minimize the differences between rule sets when switching (I will do all of my work email before updating Facebook) which will reduce the impact of switching. Secondly, prioritization at the team level provides the ability for the team to group (self-organization) the work so as to reduce rules and constraint differences between tasks. Thirdly, prioritization lets team members mentally prepare before the switch (another coping mechanism). Bottom line, prioritization is about tackling what is important first.
Isolation: Team environments tend to be noisy and interrupt-driven because IT personnel are nothing if not individualistic. Each person will have their own coping mechanisms. Find your own mechanism to block distractions; wear headphones, learn to focus, turn off IM for periods of time or consider working from home if possible. In other words, adapt to the environment without withdrawing or rejecting those around you. Remember that as noted in the first part of the essay, background noise does not have a substantive scientific basis so blasting “En da Godadiva” might not be a great idea.
Focus: Filtering or blocking things out and focus are related but they are also different. Focus is about narrowing your consciousness to contemplate a specific topic. To aid in developing focus, avoid distractions; turn off IM, don’t check emails and in radical cases hide from team members (just for a little while).
Adjust: When things don’t work out as you plan (and how many plans work perfectly?) make changes. Adjust both the process you are using and the environment to maximize your effectiveness (note, I did not say efficiency or productivity). Any process with human involvement is naturally chaotic requiring adjustments. One of the observations I have heard from studies of the Toyota Production System is that if a process is not being changed and adapted then it is not being used properly.
Process: A system or a process is required to control the flow of work. It would be difficult to prioritize and focus on a set of tasks and therefore to be productive if there was no control on how a task could enter or be accepted to be worked on. Processes like Kanban, SCRUM and even the venerable waterfall methods all include mechanisms to control the flow of work and to decide on which items should be addressed and when.
A side note in the discussion of process, is that fully committing all resources on specific tasks in a project leaves no time for probems therefore is tantamount to enforcing overtime or to falling behind schedule. All processes must allow time for both the interruptions a corporate environment always has and the overhead of the workday (email, time accounting, non-project meetings, coffee, bathroom breaks . . .to name a few). One method suggested by many time management gurus is compartmentalization. For example, blocking a period of time for heads down working followed by a window of time to read and return emails or phone messages. The goal is to have a process that allows you to work as simply as possible. This means the process needs the ability to capture to-dos, categorize, prioritize and then track work to completion (which is exactly what backlog is for an agile project or a work queue in Kanban).
At a personal level have a process, prioritize your work, filter out distractions and focus on what is important. Learn to postpone interruptions rather than switching. When interruptions can’t be avoided, shut down rather than just stopping what you doing to react. Shutting down will minimize retooling when you restart. When the urge strikes to check email or jump back into Twitter, just say no, take a deep breath and try to refocus. At a personal level I am a fan of David Allen’s Getting Things Done (GTD) and personal Kanban.
When working on projects, the multitasking problem can be addressed by adopting techniques that support serial mono-tasking with planning at a tactical level. Agile and Lean techniques are tailor-made for addressing this issue. Agile and Lean techniques have recognized the power of doing one thing at a time. Scrum and Kanban both feature isolation of tasks so that they are selected and disposed of in a serial manner.
Serial mono-tasking requires discipline to have a process and for you or your team to focus. It does not mean slowing down, but it does mean making choices. In many cases, rushing off to deal with interruptions gives the impression of importance but in the long run it probably makes your project late or reduces the quality of the product you deliver.
When the Software Process and Measurement Cast began five years ago it was the culmination of an idea that had begun percolating for many years. It did not spring into existence fully formed. The cast began as a bi-weekly show combining both an essay and an interview. We have evolved to a weekly cast. The metrics minutes essays have come a regular feature. 
