I’m not a psychologist, but it seems to me like the science is in, and it doesn’t look good for multitasking.
The idea that the brain can do two things simultaneously has been myth busted. Instead, we’ve learned that we have just a serial processor, and although it may be deft enough to provide the illusion of multitasking, on the inside it’s just an executive controller quickly switching back and forth from one task to another.
But is there anything wrong with an illusion, if the result is the same?
Well, yes. The problem is that there’s a cost to this context switching. A big one. For starters, studies have shown that we are actually less productive overall while multitasking, and make significantly more mistakes. In addition, multitasking also inhibits learning, lowers IQ, and increases stress. And as though that wasn’t enough, it turns out the more we multitask, the worse we are at it. Whew.
Despite all we know about the problems and perils of multi-tasking, however, the possibility of unitasking in the modern software development organization looks bleaker than ever. Cramped or open office environments increase the possibility for disruptions from our physical surroundings, and the ubiquity of social networking technology (e.g. email, text, instant message, Facebook, etc.) invite interruptions from beyond.
What’s more, within the world of software development, there’s a strong trend toward agile techniques, which value above almost all else communication and continuous feedback. More interruptions!
Now it might seem at this point like I’m a luddite, a social recluse, or (gasp!) a waterfall advocate, but in fact it’s just the opposite. I’ve seen first hand the benefits of both Agile processes and new tools for communication, it’s just that I think (in some environments more than others) we might take it too far. Responsiveness is important, but as the science of multitasking shows, there’s such a thing as over-communication. For the sake of our productivity, our sanity, and the quality of what we’re building, at some point we need to tune out the world, sink into a state of concentration, and get some freaking work done. But how?
Pomodoro
The time management practice of Pomodoro seems to be getting more attention lately, especially within the Agile community. The idea is simple: set a clock for 25 minutes and allow yourself to work on one task, uninterrupted. At the end of the Pomodoro, you get a quick break, and then you start again. If something pops up during the Pomodoro (an email from a colleague, a phone call from the product owner, etc.) you’re advised to record it and get back to it when the 25 minutes are up. Sounds great, right?
In my experience, it’s not so easy. If a business owner pays you a visit from 2 floors up about a bug in the application, he may not be happy when you ask him to wait 17 minutes until you’re done with your “Pomodoro”. Basically, the world doesn’t hinge on your stop watch.
Even if it did, without knowing when you start or stop the clock, it’s impossible for a colleague to know when it’s appropriate to interrupt and when it’s not. Depending on the size/activity of a team, a half dozen interruptions (of different forms) are easily possible within a 25 minute span. Just acknowledging these is enough to lose concentration.
Lastly, if each developer is on his own Pomodoro cycle, you could easily (albeit absurdly!) reach a deadlock. Joe pings Bill during Bill’s Pomodoro, and so Bill defers till after, but when he does, Joe’s in the middle of his Pomodoro and defers as well, and so on. Eventually someone’s Pomodoro has got to budge.
Introducing Power Hour
What’s needed is a shared Pomodoro, whereby the team understands when the clock starts and stops, and collectively agrees not to interrupt each other during that time. This is exactly what my we’ve created on my current project, and we call it “Power Hour” (not to be confused with any bevarage-oriented games you may or may not have played in college).
So far it’s been simple and effective. Each day we have two Power Hours, one at 10am and one at 2pm. During those two hours we all go “heads-down”, and get work done. If one of us has a question for another during that time, we wait till after Power Hour to ask it. There are obvious exceptions (bugs in production, calls from directors, free food in the cafeteria, etc.), but for the most part the sanctity of the hour is respected (even, now, by others outside of the team).
It may seem that this technique might thwart communication, but in practice it just consolidates it, often to the 15 minutes before and after a Power Hour. If I need an answer to a question before I start my work, I know I’ll need to ask my colleague before Power Hour begins, and vice-versa. This is healthy trade – rather than a work-day full of randomly distributed interruptions, discussions organically converge into concise bursts.
Who knows if we’ll have the discipline to keep up our Power Hours, but for now they’ve been a big help in countering the pressures for multitasking. I’d be interested to hear your strategies for getting quality work done, efficiently. Please share!
