Everybody likes a game!

Everybody likes a game!

Gamification is a technique that leverages a player’s innate competitive attributes to channel their behavior using game mechanics. The goal is to have individuals, teams, and organizations adopt process changes, then process improvement. Game mechanisms include badges, competitive challenges, levels, players and leader boards used in an integrated process to guide the players towards an overall goal. These concepts might sound foreign to you, but if you have ever participated in Boy Scouts, Girl Guides, Foursquare, TripAdvisor, World of Warcraft or even the venerable Dungeons and Dragons, you have participated in the use of game mechanics. Whether an app or a game, all of these examples deliver challenges to participants and then provide feedback to generate competition. Gamification motivates players to engage and adopt process changes using that competition. However, the addition of gaming mechanics to the development community can also improve collaboration if used appropriately.

Game mechanisms, such as challenges, badges and leader boards, use healthy competition and performance feedback.  For example, an organization I worked with identified set of challenge goals for a new set of development processes.  Two of the goals set for developers were that they 1) led at least 20 peer reviews as lead peer reviewers, and 2) that the first two developers that completed 50 and took a facilitation class could be designated master peer reviewers. The process improvement group posted a leader board on their SharePoint so that everyone could keep track as team members progressed against the challenges. The challenges and the feedback generated from the leaderboard created an atmosphere of collegial competition that generated engagement. The same organization holds an annual technical conference.  Attendance at the conference is by invite only (however the entire organization’s IT group could attend virtually).  As an incentive, the members of IT that had achieved the top goals in each category a month before the conference were guaranteed an invitation and a spot on a discussion panel on IT processes at the conference.

Using public leader boards can help your group identify leaders in the process knowledge community. Employees can be rewarded for participation and or their contributions to the organization’s process knowledge base. Gamificaiton not only increases process adoption rates by increasing engagement, it also helps to generate community. In the example above, one of the more interesting side effects was that loose teams formed to push members to the top of the list. A second side effect was that members of the overall development community were motivated to adopt the new processes early so that they would not be disadvantaged in the competition (if you start too late you will never be able to catch up). The bottom-line goal of gamification is to influence the organization to adopt desired behaviors.

Daily Process Thoughts on Gamification

The What and Why of Gamification

How Can We Implement Gamification?

Gamification: Game Mechanics

What Does Gamification Look Like?

Gamification and the Bartle Test

Public recognition provides motivation.

Public recognition enhances commitment.

Agile puts people and teams at the center of the development activities. Putting people at the center of the development means that commitment, motivation and teamwork are important characteristics for team effectiveness. Organizations often use rewards to reinforce commitment. Commitment, motivation and teamwork are highly interrelated and if you positively impact one all three will be impacted. Organizations typically embrace a wide range of reward structures ranging from money (e.g. cash and bonuses), giveaways (e.g. dinners, lunches or iPads) to public recognition (internally and externally).

Money is the motivational tool of choice for many organizations. The delivery mechanisms include additions to salary or bonuses. It is popular because it is generally the easiest reward to deploy. However, the problem is that it is not one of the most effective mechanisms to generate commitment or motivation for IT personnel. In a 1981 study, Dr. Barry Boehm published a ranking of the top ten motivational factor for software developers[1]. They were:

  • Achievement
  • Possibility for growth
  • Work itself
  • Recognition
  • Advancement
  • Technical supervision
  • Responsibility
  • Relations with peers
  • Relations with subordinates
  • Salary

While arguably bonuses or salary changes do have a motivational impact, the mechanisms for delivery are generally secret which reduces the potential positive benefits of recognition. For example, giving a bonus to someone might provide some personnel recognition, but if the bonus is not public there is little reinforcement of that recognition. When given a normal course of business, bonuses and salary adjustments tend to be viewed as entitlements. Also, when bonuses are competitive, they can pull teams apart as team members compete against each other. The motivation becomes to get the money, rather than than to the value that the team delivers. Some organizations try to temper the potential downside by granting the same bonus or salary increment to the whole team. I personally have never seen this tactic drive long-term motivation .

Another typical and easy reward mechanism, similar to the bonus, is the giveaway or gift. The organization grants a team dinner, lunch (paid for by the company) or the team or individual members might be given a gift certificate for a night out (it can be very effective to include enough for the spouse or significant other). This technique has the advantage of being easy to deliver and easy to make public, it allows the organization to invoke the benefit of public recognition. A twist on the dinner or lunch reward is to have the project sponsor, or another relevant senior leader, act as the master of ceremonies. The senior-level participation increases the recognition component of this activity. As a side benefit, involving the families or significant others of team members can also increase team bonding. For example, I still remember warmly an event several years ago where a senior business stakeholder “threw” a picnic for the team and all family members one Friday afternoon. It was the day I learned how to play cricket. The team recognition from the sponsor was heartfelt and not perfunctory. The team would have done nearly anything for that sponsor. Gift cards for a local eatery would not have had the same impact.

In Boehm’s hierarchy of motivators, achievement, doing cool things and recognition ranked at or near the top of the list. Almost any of the motivators is improved by recognition. To be effective, recognition needs to be for a real achievement. In the business world, not everyone gets a blue ribbon for just playing, and rarely do achievements like perfect attendance rate public recognition. Consistently delivering business value and high customer satisfaction are  worth recognition. Like before, a twist that makes recognition even more powerful is having that recognition delivered by the business sponsor or relevant senior executive. Recognition works on many levels building self-esteem (TA or Transactional Analysis is on the list topics for the Daily Process Thoughts), team esprit de corps (recognition reinforces the value of team behaviors) and trust (delivering on commitments is important for building trust).

Organizations use a wide range of rewards to reinforce commitment with varied results. The results of rewards on commitment and motivation are rarely measured. And in many cases, the techniques that are used are not the most effective, but rather the most expeditious. On Maslow’s Hierarchy of Needs, most IT practitioners and teams would be closer to the top of the hierarchy (self-actualization), than to the bottom (physiological needs – food and shelter). This suggests that rewards that focus on self-esteem, recognition and achievement will have a larger and longer term impact on team’s commitment and motivation and teamwork.


[1] Boehm B. W., Software Engineering Economics, Prentice Hall, 1981