Context switching and efficiency -- Kanban to the rescue?
Listen here:
You can read the article by Mattias Sander here: Become more productive and motivated. The article originally appeared in the ISTC Communicator (Summer 2016).
Sander begins general and describes Lean principles:
The idea of Lean is to maximize customer value while minimizing waste, thus creating more value for customers with fewer resources.
He explains the main reasons for waste. One of these reasons is “Motion”:
Motion is the waste of movement around a product or work-item, for example, reaching too far to grab a tool.
These abstract principles about Lean eventually get more specific, focusing on the familiar problem of multitasking and context-switching, which turn out to be a sizable drain on efficiency:
Task switching could be considered to be Motion. Some estimates say that you lose 40% of your time because of task switching.
Here Sander gets into Kanban as a solution to task switching. The basic idea of Kanban is to limit the number of tasks you’re doing at a given time so that you aren’t constantly switching activities and losing the context you need to be productive. With Kaban, you break up your tasks into 3 basic categories:
- Backlog
- Doing
- Done
You allow only a limited number of items (for example, 3) in your “Doing” category. Sander explains:
The more we have [in our Doing category], the slower we produce because of the task switching. We can use the Kanban method to reduce our work in progress, and to help us keep track of what we need to produce.
I’m constantly bombarded with emails, instant messages, social media notifications, and meetings, not to mention having multiple projects I’m working on, so it’s hard to not get swept into the inefficiency of multi-tasking.
Sander’s article resonates with a post I read by Joel Spolsky — Human Task Switches Considered Harmful. Spolsky talks about the inefficiency that occurs specifically when programmers have to switch tasks:
The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.
Spolsky argues that rebuilding the necessary context to do a complex task like programming is what creates the inefficiency. Consequently, Spolsky says programmers should stick to one task only:
As it turns out, if you give somebody two things to work on, you should be grateful if they “starve” one task and only work on one, because they’re going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once.
I currently have two main projects at work, but both could easily occupy my work full-time. In an ideal world, I would simply offload one project onto “someone else.” Since that “someone else” does not exist, I have to figure out how to juggle both projects without the drain in efficiency. Once I get moving in one direction, I find it really hard to put the brakes on and start accelerating in another direction. The time it takes to stop and then restart in the new direction creates the inefficiency, which gets multiplied the more times I stop and start.
Assuming it’s not possible to reduce the number of projects and work, perhaps the strategies of Kanban can make me more efficient in my attempt to balance the two projects?
Here are some options:
Option 1. Suppose I dedicate a full week to Project A, and the next week to Project B, and the next week to Project A. This would give me the momentum of a full week of context. But it also drives the other project further into oblivion, making it harder to resume that context when the new week begins. It could take an entire day to re-contextualize with the new project.
Option 2. I could dedicate one day to Project A, the next day to Project B, and the next day to Project A. This might enable me to preserve more context between the two projects, without entering the oblivion stage. But this flip-flopping between days seems like exactly the kind of frequent context-switching that Spolsky warns against.
Option 3. I could alternate tasks between the two projects. One task from Project A, then one from Project B, and then one from Project A. With this close context-switching, I won’t drag the other project into oblivion, but will this approach tear away at my insanity? Would this create even more inefficiency from the constant context switches? Is it ever possible to sustain two contexts at the same time?
I’ll have to experiment. Regardless of the waste created by context switching, one strategy of Kanban is to avoid wearing out users from task overloading. If you only have 3 active cards in your Doing category at once, you’re less likely to be overtaxed and stressed out from trying to do everything at once. In David Anderson’s book on Kanban, he notes one reason for implementing Kanban with his team was to protect his team from the constant demands of stakeholders and provide a sustainable pace to be productive in the long run.
Even if I lose effiency through context switching, at least by following Kanban I will re-gain some efficiency by maintaining productivity in the long run.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.