The importance of fun in the workplace

One of the key elements of the Cloud Garage Method is Culture. That single word encompasses a whole range of practices about how we manage our projects, and how we interact with our stakeholders and each other. One of my favorite parts of the Cloud Garage culture is the fact that it includes a fun work environment.

Although we all like fun (I hope), it’s often seen as slightly unprofessional – fun is something that happens outside work. Most of us would be a bit nervous about writing, “I’m great fun” on our CVs, or reporting to our boss how much fun we’re having in the office. Nonetheless, fun matters a lot, and not just because it’s nice.

The evidence that fun boosts productivity is compelling. A happy work environment means fewer sick days, harder work, and greater productivity (links resides outside ibm.com). Research shows individuals with a positive mindset are 31% more productive than those with a negative mindset (link resides outside ibm.com) – or even a neutral one. Think of it like a placebo effect (link resides outside ibm.com) for the workplace; just as taking a sugar pill can trigger a healing effect as powerful as that of a ‘real’ drug, thinking tasks are achievable actually makes them so.

Although a sustained happy mindset with underpinnings in a positive company culture is clearly best, even a very brief episode of fun can boost productivity; one study found that watching a comedy video right before doing an exercise (link resides outside ibm.com) boosted participants’ performance by 12%. Just a few laughs already makes us more effective employees.

There’s another aspect to fun. Not only do we work more effectively when we’re having fun, activities that are fun are often more effective.

Many of the activities we dislike, we dislike because we know that, fundamentally, they’re wasteful. Think about interminable meetings, status reporting, nitpick code reviews, bureaucracy, manual deployments, repetition … not fun, right? Many of those are also not useful – or at least, the same value can be achieved in a much more efficient way which is also more entertaining for everyone involved.

The best approach to making a workplace more fun doesn’t start with adding ball pits, beer slides, or silly ties – not even compulsory comedy videos. Forced fun is an oxymoron; the best fun has an element of spontaneity, and definitely no element of coercion or institutionalisation. A corporate culture can enable fun, but it can’t mandate it.

Instead, the starting point should be removing un-fun – the daily grind of wasteful activities that drain morale. The good news is that we can fix these – and we can become more efficient along the way. Modern development methodologies, such as the Cloud Garage method, focus on increasing feedback and removing cost. A happy side effect is that they remove a lot of the tedious low-return activities that used to take developers away from delivering customer value.

Businesses live and die by the quality of their applications, and how well their development team understand them. Having more than one set of eyes on business-critical code is essential. Traditionally, businesses enforced formal code review processes to try and ensure code quality. This was often not so much fun for the person being reviewed, who was having their work criticised, and it wasn’t great fun for the reviewers, either, who had take time away from their own code. Problems identified were often so trivial they weren’t worth fixing (bikeshedding), or so fundamental that fixing them could involve rewriting days’ worth of work.

Pair programming takes this critique-based process and turns it into something much more collaborative. When I moved to the Cloud Garage I wasn’t sure if I’d enjoy pair programming all the time, but I discovered I love it. I learn so much every day I pair. Having a development partner makes tough problems less daunting, and it means when something hard works there’s someone to share the excitement with.

In the Garage, we write the tests first, and we use them to guide both our implementation, and also our thinking about what we actually want the thing we’re writing to do. This approach is great for quality, but it’s also fun. Watching the red tests go green is gratifying.

As we develop, our aim is to keep our implementation clean so that we keep the tests green, and each all-green test run is a tiny thrill.

In the London Garage, we’re evaluating the #noestimates (link resides outside ibm.com) approach to sizing. Sometimes, pointing meetings can add a lot of value and help everyone in the team understand what we’re trying to do and what the tricky bits will be. Other times, they seem like an exercise for the sake of it, especially if we get bogged down in small details or small number differences.

On the project I’m currently doing, we didn’t do story points when we started, but then we did a pointing exercise midway through the project because at that point the answers mattered. That worked well for that situation, but other projects may be different. My guide at the moment is a fun-based one – if the pointing meeting is interesting, we’re getting value from it. If there are yawns all round, it’s waste and we should skip it.

Repetition is boring. Automating stuff is fun. Once tasks are automated, you’re free to go do other more valuable work.

The great thing about automation is it helps in a whole bunch of domains, from progress tracking to release deployments to machine maintenance. If the cost of automating a task is less than the time it will take to do the task repeatedly, take advantage of your skills, and automate it. Have fun doing so!

Once we’ve got rid of as much un-fun stuff as we can, and eliminated a whole bunch of waste along with it, we can move on to having fun. At this point you can bring out the Hawaiian shirts if needed, but fun can’t be forced.