Introducing fun at work for Software Engineering team

Question

As a manager of a 20 member software engineering team, I would like to introduce some fun element at work. This is mostly to bring in a good team synergy, fun, motivation and cross communication in a team that is lacking all of these.

I myself was looking through Gamification videos like Speed Camera Lottery and was inspired to try something like this in my team. ie., rewarding positive behavior than constraining people with a lot of parameters to evaluate them.

What I would like to introduce is a system where I can kick-start this kind of awarding positive behavior by fun ways. For instance, I would initially start by awarding all engineers a seed fund of points, say 100 each and they have to spend and also earn points from others by helping, communicating, or motivating others.

For instance, as a simple case, a developer can send an email with a question to help him or her re-frame the question he is going to ask to customer, and is going set a value, ie., award 10 points to anyone who helps.

Help review this email that I am sending to customer about Dashboard feature. 10 points will be rewarded to the one who helps me with this. With regards, -O

I would like all of this to be exchanged within an email system but don't mind if its can be accomplished by an existing web solution. The important part is the fun element of exchanging the points and cashing it end of the month back to me to get some sort of gift or lunch coupon. I know the idea becomes a project in itself as all other cases need to be handled.

Has anyone introduced such a system in their workplace? What systems are used or anything close to what I would like to accomplish?

I might not be clear from a reader's point, so please feel free to ask me more information. Thanks in advance.

Answer 1

TL;DR

Gamification is inherently competitive, which is contrary to the "succeed or fail as a team" concept that underlies many agile methodologies. That doesn't mean it's a bad idea; it just means it's not well-suited for use with frameworks like Scrum or Extreme Programming. Your mileage may vary with other methodologies.

Competitive Nature of Gamification

According to one Wikipedia article on gamification techniques (emphasis mine):

Gamification techniques strive to leverage people's natural desires for competition, [personal] achievement, status, self-expression, altruism, and closure.

This can be quite healthy, but competition or status-seeking is contrary to the self-organizing, team-based structure of Scrum. Having said that, it is certainly possible to structure a point system that rewards cooperation, mentoring, knowledge sharing, swarming, and pair-programming, but in my personal experience I have found that teams that embrace these objectives often find the practices to be their own reward.

Focus on Team-Based Rewards Instead

Rather than promoting individual achievement, I tend to focus on team-based rewards. Especially during the transition from command-and-control to agility, I've often found it helpful to reward the team with lunches out or pizza parties for things like dead-center estimates or swarming a late story with "all hands on deck" in order to finish within the current sprint.

It's important not to incentivize the wrong behaviors, such as padding estimates or sweeping under-performance under the teaming rubric. However, this is generally taken care of by having routine, honest retrospectives that include evaluation of the metrics themselves.

Measure the Operational Effectiveness of Gamification

As with any other project management control, the utility of the technique varies between teams and between organizational cultures. You will also tend to get what you measure, so make sure the rules of the game align with your intended goals and continuously check that the control is operating as designed.

If you aren't a Scrum shop, or you don't do retrospectives, then you may need other controls to monitor your gamification controls. That doesn't mean it's not worth doing, but it does mean that the issue is likely to be more complex than it appears on the surface.

As always with project management, your mileage may vary.

Answer 2

Robert Austin wrote a short, devastating little book, Measuring and Managing Performance in Organizations, that neatly demonstrates why and how most personal measurement systems are doomed be either at best distortionary or at worse actively dysfunctional.

The problem is that you're introducing personal measurement. Under selected circumstances, that can work very well. However, if there is even the suspicion of a hint of a whiff of a chance of a possibility that it will ever be tied to any kind of reward or punishment, the system will be gamed. When the system is gamed, you now have two problems.

First, any information derived from the system is misleading. It tells you things that aren't true; if you act on them, you may make costly errors.

Second, you distort the mix of work that gets done. "What gets measured, gets done". Unless you can measure every important dimension (Austin calls this "total supervision"), you will distort the mix of work. Introducing new metrics doesn't fix this, because in practice any mix will either collapse to the "true" metrics that management clearly favours; or an index metric is produced which itself can be maximised by fitting activity to the weightings in the index metric function.

There's also, as CodeGnome pointed out, the problem of competition. Insofar as any system sets up a zero-sum game (for me to win, someone else has to lose), it creates a rational disincentive for cooperation between players. But software is usually a cooperative enterprise.

Using team incentives will resolve the zero-sum problem but does not resolve the problems of misleading information and distorted effort.