The Zeigarnik Effect

In this article, part of my series explaining better ROI from software development, I’d like to look at the Zeigarnik effect.

What is the Zeigarnik effect?

“The Zeigarnik Effect is the tendency to experience intrusive thoughts about an objective that was once pursued and left incomplete” Psychwiki

It is a psychological effect that recognised that there is a “need” to complete a task once is has been initiated. The lack of closure can then lead to the task staying “on your mind” – which, in itself, is a finite resource.

Simply put, the more tasks we are juggling at one time, the more we have occupying our minds – and the less effective we become.

And it is this effectiveness that is important to the ROI on software development.

The more effective (or productive) an individual or team are, the better ROI you achieve.

So why the psychological stuff?

Because it is important to understand how people think, what is good for effectiveness and what is not.

The Zeigarnik effect talks to the negative that can creep into an individual or team that feel that they have too much work. They feel they are drowning under the workload. They are probably starting to feel overly stressed (some stress is good, too much is really not), they have difficulty concentrating, they procrastinate and make mistakes – it becomes a steady decline.

I'm sure we have all felt this at one time or another.

On the reverse side of the effect, by completing a task you are cognitively freeing up space. You don’t need to think about it any more – it’s done. You also get that positive feeling of closure – almost a little buzz.

If you talk to highly productive teams you’ll find they are feeding off the positive energy of that buzz. Every time they can mark a task as done they have sense of achievement and closure – and it becomes somewhat addictive in its own right.

How does this effect software development?

In numerous of my articles I've talked about the Intrinsic Motivators described in Daniel Pinks book Drive.

We want to engage the Intrinsic Motivators wherever possible as this is where the individual is self motivated.

The positive effects of the Zeigarmik effect help us encourage those intrinsic motivators.

Fun is a great motivator.

What? I'm paying them to work, not to have fun?

Oh, how I've had this argument.

Working hard and having fun are not mutually exclusive.

We've been brought up to believe that work has to be serious. If you’re having fun then you’re goofing off. You’re not being professional.

This is complete rubbish.

There is nothing wrong with encouraging fun. If anything, by discouraging fun then you are costing you organisation money. You are being unprofessional.

Simply put:

Fun = More Intrinsic Motivation = Better Productivity

It obviously isn't the entire story – I'm not suggesting that you have your developers play ping pong for the entire day – I'm just highlighting that you shouldn't be discouraging fun.

Ok, rant over.

So what does this mean from a practical basis?

From a practical basis, going back to the Zeigarnik effect, we need to think about how we push tasks into our development team.

Predominately, how many we push into them, and how quickly.

If we flood them with every possible request we can think of and then ask for it all ASAP then we soon trigger the negative effects.

If however we stagger them in over an appropriate timeframe, then we get the positive effect.

You will get better productivity from the latter approach than the former. You will actually get better ROI.

In a previous article, I talked about the sustainable development & constant pace underpinning the Agile Manifesto. To complement this there are various Agile Software Development practices that encourage that sustainability by following the principles of controlling the amount of work over a period of time.

You will commonly see things like:

• Timeboxes – a specific period of time in which an activity must occur. It must not exceed that activity. We are generally using Timeboxes to produce an appropriate cadence to the work. It provides a natural barrier to trying to do too much at once.
• WIP Limits (Work In Progress) – by setting a limit of how many things that can be WIP then a team is forced to stay within that limit and finish open tasks. For example, if they have a WIP of 3 – then they cannot start on the 4th task until one of the first three is completed. This enforces that they aren't downing.

These all help to focus on getting tasks done as efficiently as possible – freeing up the team (and cognitive functions) for the next task.

More of the same

In the next article I’ll look at the very closely related Flow.