R.A.C.E. Gamification Framework for Building Happier and Healthier Teams-EN

“The creation of something new is not accomplished by the intellect but by the play instinct acting from inner necessity.” – Carl Jung

Games are Inherently About Improvement

When you play a game, you are focused, challenged, and engaged. These qualities are something that many businesses are looking to improve or increase in their teams. So why can’t work be like a game? What if we take the best parts of play and apply it to our work? Wouldn’t we see happier, healthier, and more productive teams as a result? 

I took this as motivation to create a framework called RACE which stands for Robust Agile Cooperative Engagement Framework. I designed it with the hopes of driving higher ownership of the team’s goals, creating motivation for consistency and introspection, and increasing communication… and, I’m thrilled to say that we’ve seen some great initial results.

One of the surprising benefits of turning work into a game is that it abstracts the work conversation into a more comfortable space for the participants. This abstraction allows for people to be more open by reducing the stress of talking about yourself in relation to the work being performed. As a system, it is designed with positive rewards for incremental improvements to help increase the likelihood of the improvement becoming a habit in the future. 

Note: The gamifying approach that I cover in this article was designed primarily to work within the Scrum framework but can be adapted to other agile frameworks as needed.

The Framework

This gamifying strategy leverages the existing Scrum meetings in new ways to drive focus on improving, not just doing the work. For instance, the gamification objectives (described below) are brought up in the Standups to keep a focus on the desired improvements throughout the Sprint. Objectives are also reviewed in the Retrospective to discuss both the successes and failures of the Sprint and related objectives. The Retrospective should also be a place to generate new objectives based on areas the team wants to improve upon.

In Planning, those takeaways from the Retrospective are put into action by inspecting the pre-existing objectives. One way we provide introspection is by asking the following question: “Are we keeping the objective the same, are we improving the objective, or are we removing the objective as we have succeeded in the goal of improvement?”

The Objectives

Objectives are designed to be evolving goals that improve the team’s performance in areas such as quality, delivery speed, or any other area related to their work that the team wants to improve. I recommend measuring success for Objectives on a percent basis or on a sliding scale wherever possible.

Current Objectives

Possible Points

Actual Points

How to Score

Standup/Ceremony Attendance

10

8

% of all the meetings attended

1 point = the whole team showing up or communicating prior to Standup why they would not be able to attend

1 Planning Swarm discussing stories + 1 full team Swarm on 1 story

10

10

At least 2 Swarm occurrences in a Sprint with QA. Must Swarm if a Swarm is triggered through date, setting -5 points per missed Swarm, up to -10.

Post deployment issues

10

10

Per issue found = -2 points

The Points

Objectives are assigned point values which the team has to “cash in” for a reward. By using scoring based on either the percentage or sliding scale approach, points can be awarded partially, i.e., 50% = 50% of the points. This allows for partial success, versus having all or nothing rewards that can be demotivating to the team.

We want to reward improvement more than success, which generally is an incremental process. This is also why an objective that is consistently at 100% success should be removed or made more difficult.

Example:

• Objective: We want to complete 100% of what we commit to at the start of the Sprint.
• Point Value: This Objective is worth 10 points to us.
• Points Achieved: If the team achieves 50%, they get 5 points. However, if this objective is achieved at 100% for multiple Sprints, the team should challenge the efficacy of having it as an objective still and promote removing it or making it harder.

By design, this system is set up to reward the team for success, even as a partial reward, instead of punishing the team for failure. This is designed with the intention to allow both high performing teams and teams that are struggling to be rewarded for growth relative to the team.

Current Objectives

Possible Points

Actual Points

How to Score

Standup/Ceremony Attendance

10

8

% of all the meetings attended

1 point = the whole team showing up or communicating prior to Standup why they would not be able to attend

1 Planning Swarm discussing stories + 1 full team Swarm on 1 story

10

10

At least 2 Swarm occurrences in a Sprint with QA. Must Swarm if a Swarm is triggered through date, setting -5 points per missed Swarm, up to -10.

Post deployment issues

10

10

Per issue found = -2 points

The Rewards

First, the team brainstorms on reward ideas that they feel are valuable to them. After a list of rewards is gathered, it is taken to leadership who then approves the team’s reward list and assigns the point values.

I recommend using buckets like small, medium, and large and filling in points based on those buckets. We consider our reward buckets to be:

• Small is a reward that a reasonably performing team could receive within a Sprint and something that leadership is willing to provide on a per Sprint basis.
• Medium is achievable 2-3 times in a quarter.
• Large would be achievable once a quarter.

Another way to help assign point rewards is around a block of time and/or money. The team comes up with the rewards, and instead of weighted buckets, leadership uses a base of money and/or time to allocate points. This approach allows leadership to create a broad scale that makes it easy to judge a particular reward against a standard set of points (i.e., 1 hour for the team = 50 points, or 20 dollars for each person = 75 points).

Example:

Item

T-Shirt Size

Points

Notes

Team trivia 

S

60

1 hour team time

Random small swag item 

S

75

item x 5

Extra personal development time for the next Sprint

S

60

2 hours team time

Happy hour for the team

S

60

1 hour team time

Gaming hour

S

60

1 hour team time

Get steam or other team game

S-M

Depends on game

Game cost x 5

General Rules

These rules are intended to create an environment of friendly competition, team focus, meaningful rewards, and lessen the probability that people “game” or manipulate the system.

No direct monetary rewards allowed.

After servicing basic needs, money does not motivate as well as other motivators such as autonomy. Studies have found that the amount of money generally increases over time for the same amount of motivation versus intrinsic motivators. A team lunch does cost money, but in terms of providing motivation, the money needed to get the same motivation return is less over time than that of direct money rewards. For those interested, here’s a link to an article on the nuances of monetary versus non-monetary rewards. Also, for the best breakdown, Daniel Pink’s book Drive is an excellent resource.

No individual rewards. The team succeeds or fails together.

The highest producing teams own the work together instead focusing on specific role contributions. As an example, if a Developer helps QA speed up testing, then that team is more likely to increase value output rather than a team in which Developers focus solely on developing software. The same can be said for QA explaining how they are going to test the software to Developers before testing. 

In short, if a system rewards individual roles, then the focus becomes on “staying in your lane” and only completing their portion of the user story. Conversely, by focusing on the work being completed as the measure of value, the team collaborates together on how to deliver it efficiently. 

Everyone gets to set Objectives in the game.

It is recommended to have a 50-50 split in terms of Objectives to start with. The PO and SM get half (or 25% each) and the team sets the other half of their goals. The simplest way to start is to ask the team what they want to get better at in terms of their delivery of value. There are generally many things that fit this categorization, and with team discussion, they can be refined and iterated on over time.

Everyone is an adult and will be expected to play the game as such, or the game will end. (i.e., If the rules you set are too easy and don’t cause improvement, then they should be challenged.)

Objectives are the way to score points in the game. The PO, the SM, and the team all set Objectives that they want the overall team to improve on. The goal is to provide agency to the entire team to not only identify potential ways to improve, but to also be rewarded for resolving them.

Any team member can challenge an Objective.

Challenging is when a team member might think the Objective is too hard, too easy, or simply no longer relevant. This engages team members to bring things they are passionate about to the group to improve.

Objectives by design are to become more difficult as the team meets the objective consistently.

This game is designed to encourage growth in the team’s ability to deliver value. If the objectives do not change in response to the team’s achievements, then the game ceases to have value and teams are naturally encouraged to stay in their current state. This is where teams can throw twists and eventually get nitpicky on how they want to improve

Points will be awarded on a percent or sliding scale, wherever possible.

The intent of this system is not to score every point in every sprint. In fact, if you are achieving 100%, why are you bothering to make it an objective? The intent of this system is to improve and to recognize that improvement. Using a point system allows for the points to be awarded in relation to how well the team succeeds. The team should always be rewarded for the effort in comparison to the Objectives they have set. This also has a side benefit of spurring constant discussion on how to gain more points by becoming better at the current Objectives.

The whole team must agree on what reward to choose to “cash in”.

The whole team should receive the reward.

The points required to receive a reward must be relatively equivalent to the “weight” of the reward.

The goal is twofold; players receive rewards they feel are valuable, and the rewards remain within the budgetary requirements of leadership. This rule requires a lot of conversation between the leadership (that is providing the reward) and the team representatives, the PO and SM. Not all rewards have to be cost-driven; team gaming for an hour at the end of a sprint is a good example of this.

Points expire at the end of a quarter (or similar time box).

Games are meant to be challenging, but also rewarding. If a team does not reward themselves, there is potential that the game loses its motivation and stops producing results.

Rules are meant to guide good practice but not be enforced unilaterally.

Everyone’s teams are unique, and because of that, sometimes these rules will not work without adjusting the rules to match the team. The goal in explaining the intent behind these rules is to allow for understanding that can be weighed when altering or changing them.

The “Win” for the Company

Anecdotally, I have seen a team improve over 100% in value delivered (measured in effort) while increasing “committed to completion work” in a Sprint to 100%, and they maintained this success rate over the course of several months. The team has also been more engaged, more willing to push back, and more vocal when they have encountered problems that have affected them. While this might not work for every team, it does show that there is a place where this type of gamification can be successful in improving team performance and being enjoyable for all participants.

There is a second part to the quote I used in the beginning of this article:

“The creative mind plays with the objects it loves.”

What Carl Jung is pointing out is that when you enjoy something, it is a natural tendency to want to maintain and even improve what you enjoy.

Gamifying work is intended to take that drive and apply it in the workplace through making work more enjoyable. This framework isn’t designed to be some sort of static answer to that goal; instead, it is a foundation to customize with the intent of making your work environment a happier, healthier, and more productive place to be.

Please reach out and let me know if you have any questions or would like to talk about using gamification on your team.

Thank you!

Marc

Are your teams happy and healthy?

As a Netmind Student, Marc has taken several classes from us to help him learn to develop gamification tools for his team. One of the most impactful training areas for learning how to motivate his team was in Agile Coaching. 

More on Agile Coaching