Tolstoy once wrote, "all happy development teams are alike; every unhappy development team is unhappy in its own way". And after 20 years as a programmer, I can attest to at least one sure-fire route to unhappiness:
It's the beginning of the sprint. Everything's been planned, estimated (if that's how you roll), and assigned. You have a few features on your plate, and are eager to get going. Starting with the most critical one, you dig in for a day, get a plan together for how to tackle it, and begin coding.
Another day passes and you get about halfway through when the project manager swings by your desk. "Hey", he says, "I know you've already started, but a business priority has changed, and we need you to work on this different feature instead. Finish this new one off now, and then you can get back to your original work".
I'm not sure about you, but this drives me freaking crazy (at least it does when it happens often). But should it? I mean, I'm being paid by this company, and it's up to them to set their own priorities, right? If they decide there's more value in a different feature, that's their call. Further, I'll get back to the original feature eventually, and if I don't, who cares - I learned a few things in the process of digging in, and probably have a better grasp of the application as a result. What reason do I have do be frustrated? And yet I am...
This internal tension has plagued (or at least puzzled) me forever. Why do I hate leaving tasks unresolved so much? And I think its not just me - most of my colleagues seem to get just as frustrated when it happens to them. But why? Recently, while reading the book Irresistable, I found an explanation.
In psychology, there's a well known cognitive bias called the Zeigarnik effect. It states, simply, that an incomplete or interrupted task will be remembered better than a complete one. The phenomenon was coined by Bluma Zeigarnik, a psychologist who noticed that waiters had better recollections of orders that were unpaid. As soon as an order was completed, the waiter effectively flushed it from memory. In her paper Finished and Unfinished Tasks, she explains:
"When the subject sets out to perform the operations required by one of these tasks, there develops within him a quasi-need for completion of that task. It is like the occurrence of a tension system which tends towards resolution. Completing the task means resolving the tension system, or discharging the quasi-need. If a task is not completed, a state of tension remains and the quasi-need is unstilled."
This hits the nail on the head for me. When I start development of a new feature, there's a non-trivially strong force within me that wants to drive it to completion. If I'm asked to table that feature in favor of something different, my brain can't completely let go of the original task and so I can't fully focus on the new task at hand. The details of the original task are still churning in some background process in my brain.
Further, my guess is that the Zeignarnik effect is probably cumulative as well. The more tasks interrupted, the greater the tension and frustration. And for some, this is the rule rather than an exception. You get into work intending on finishing off some feature, but then get pulled into a meeting to discuss something different, and then get pulled out of that meeting to work on a production defect, and so on until the day ends and almost nothing was fully resolved. Ultimately frustrating.
Adjustments can (and probably should) be made in an organization to avoid this effect, since the effectiveness, mental clarity, and possibly even sanity of their developers depend on it. First, of course, we should strive to limit interruptions and let developers close open loops before forcing new ones upon them. Many teams have already started doing this through the adoption of Kanban and work-in-progress limits. Additionally though, in environments where interruptions are rampant, perhaps tasks could be designed to be as fine grained as possible, allowing developers to finish something before being pulled off to work on the next. Lastly, it's possible the best solution might just be to strive to overcome our innate mental wiring - when you get frustrated over switching away from a task, just acknowledge it's just the Zeignarnik effect, and do what you need to do.
Anyway, I'd be interested to hear about your experiences. Is the Zeigarnik effect real, and does it cause frustration? What do you or your team do to address it?
