Many years ago, when I was first introduced to scrum, I was so excited that there was a philosophy out there that considered an employee’s work life as something to enhance. I could not believe what I was reading: “Scrum will consistently enhance individual development and quality of life” (The Scrum Papers). Unfortunately, this failed to be true, but the failure has nothing to do with scrum. It has a lot to do with the way it is implemented.

As an agile coach and trainer, I see development teams struggle to meet the demands on them. I have had calls where teams are described as totally unmotivated, as not knowing what they are doing, as unproductive, and the list goes on. Many times I am brought in to find the cause, but when I find it I can only apply short-term techniques, because teams are not given the time they need.

I know that the lack of motivation, lack of cohesiveness, and lack of performance are the symptoms and not the root causes. The problem is not due to lack of will; it is due to a series of factors that influence performance. One of these is lack of soft skills, and while scrum and other agile practices can make some improvement if applied correctly, it will not change the makeup of your team. These soft skills need time to be taught and nurtured—time many transitions do not give teams. With the problem in mind, I searched for a solution. The need to do more to help the teams I come across every day drove me to design my first game.

Game-based learning

I know games are not a traditional solution, but sending teams to team-building exercises once a year just does not solve the problem. Sure, they have fun and will learn a thing or two, but when they get back to work, everything is back to being the way it was.

I decided on game-based learning because it could continuously reinforce soft skills while improving the quality of the team’s work life. I wanted teams to look forward to coming into work, and not dread the very idea. I wanted a place where teams would be able to escape.

I took three main steps in designing my game.

The problem

To start my game, I revisited all the reasons why I wanted to endeavor in this path, in order to maintain focus and stay true to what I was trying to solve. I wanted something that could help make an agile transition for individuals and organizations easier. This meant creating something to help teams learn how to work together. It is very easy to lose sight of what you are doing when designing your game. There are lots of fun things you may want, and can execute, but that will not necessarily get you to the result you want within a budget.

The clearer you have in mind the problem you are trying to solve, the more likely you will keep on track. Write it down and post it where you can see it.


The storyline helped me take the game to where I wanted. It may not be an award-winning storyline, but it has the elements I needed to create the escape environment I wanted—one in which team members could escape and be free to be themselves, make mistakes, and learn from them.

I created the story of a tribal quest and named the tribe something symbolic of the teams’ quest. “Akeakami” in Polynesian is “a seeker of wisdom.” I included in this quest the necessary elements of life to symbolically relate to work life.

I debated with myself whether to add design before storyline, because I really did both at the same time. Much like in agile, I produced just enough of a storyline to get to designing. I did not want to wait a year to have my game out.

As we moved further into design, I continued to develop the storyline. Don’t get too caught up in getting your story perfect.


Here is where all the thinking about what you are trying to solve comes in handy. You can get lost in the landscape of games, and there are plenty of elements to consider, ranging from puzzle games to simulation games. Let’s go over a few I considered:

  • Puzzle games are brain games
  • Decision-based games are choice-driven games; the player’s decision lays out the path
  • Combat games are all about fighting opponents
  • Adventure games use puzzle-like features and a story to fill in characters
  • Simulation games use real-world equipment to train professionals
  • Multiplayer games allow players all over the world to play within the same “room”

Decisions, decisions!

In my case, I wanted to solve team problems, so for me it was a no-brainer to make a multiplayer game to allow teams all over the world to play together. You see, in a world where teams are distributed, this is a “must-have.” But I also wanted to make teams think, so I included puzzle features, forcing teams to think about how they will reach the goal of each level.

Another must-have for me was adventure. I wanted to create an atmosphere where teams could lose themselves, so I created a story to support the design.

I checked the decisions against my goals in case I missed anything. These were my goals:

  • Force teams to work together—place them in the same virtual room
  • Force collaboration—game mechanics need to enforce this
  • Force teams to communicate—game must allow teams to be in the same virtual room to communicate
  • Challenge and motivate teams—game must have a puzzle to challenge teams
  • Remove them from their current environment—game must have a storyline

With these decisions made, I needed to fill in all the missing pieces. Now that I could place a team in the same room, what would they be doing? They would be solving a puzzle, but by itself that was not enough.

I relied on my coaching and training skills to guide me the rest of the way. You see, when I teach scrum and other agile practices, I use gamification similar to what Jane McGonigal does on TED talks. (If you have not heard her, you should look her up; her talks are educational and she is awesome.) I use quick games that correct team behaviors. An example of this is a ball game that places managers around a circle; they are given certain rules and time to complete. Depending on what I want to drive in, I change up the game. This could mean making rule changes on the spot. Its purpose is to create empathy for a team and to show how it impacts a team’s performance.

The next step is creating rules that will force teams to collaborate. For example, the game will not start without all the team players ready, and the game will not end until all the team members have, in the case of my game, reached the “crystals of life.” Rules help drive the game to serve your goals.

I also placed a timer in each session, making the game more challenging, but it served another purpose. I wanted the game to continue to be played so that it would reinforce these soft skills, but as I mentioned, earlier teams are not given much time to learn to work together. What I did was time-box each level into three to five minutes. This meant teams could play a game quickly before a scrum daily, or a retrospective, or any meeting without impacting their work.

How will you reward the learner?

The other element that you need to consider when designing is a reward system. You need to keep team members motivated and coming back to play. In our game, we use two forms of rewards: badges and rank rewards. Players obtain badges for completing a level and for being the best at a specific skill. For example, the best catcher or thrower earns that particular badge.

When using rank, the player acquires points for each action. I had to be careful here because I did not want team members within the same team to compete against each other. Competition is healthy, but when you want to form a cohesive team, you don’t want team members competing against each other. So I decided to reward points to the players who helped their team members, and when the whole team obtains a certain amount of points, they are rewarded with the highest badge. If there are multiple teams, the “best team” badge is earned by the team that collaborates the most; this could go a long way toward getting a little competition across teams going. From an agile transition, it is a great way to get momentum!

What does my game look like in play? Here is a video of the first version of the game (it is a desktop version); this is the fourth time this team played this game—it took them that many tries to succeed. You can also download a free version of our new game, Akeakami Quest, for iOS or Android.

I hope my experience gets you on your way to designing your first game. Again, think about what your minimum viable features are, your must-haves. Don’t try to get everything in the game all at once. Stick to what you are trying to solve.