Human Powered Calculator – an agile learning game

I’ve recently had an extremely cool opportunity to do Agile introduction to a large software development group. One particular challenge was that the group was highly dispersed geographically, across many different offices. The same introductory session was given multiple times but in totally different settings: Once to the people in the same office (Run 1). Once entirely over Webex to the dispersed teams (Run 2). And finally once to a mixed audience, part of the group in the same conference room with me and part remote (Run 3).

Technically, if all I was doing was talk and show slides the audience location was not necessarily a big deal. However I wanted to add a few games into the mix. And in particular, a game that gets people to believe in and experience “Self-organizing team” concept. Looking around I really liked the “Ball point” game. This game works well if you are doing everything in one location, passing tennis balls over the phone is not that easy (although there might be a creative way to do it, would love to hear if someone got it).

What I want to present here is the game I came up with, which introduces the same concepts, but works both for in-house and in a remote setting. The game is called “Human Powered Calculator”. It goes like this:

Human Powered Calculator

Prior to the game each participant receives by email a set of “operations”, one operation per each game round. In my case I’ve limited to 5 rounds.
In the email they are asked to keep all their operations secret until they hear otherwise.

Let’s suppose we have two players A and B, with the following operations

Round Play A Player B
1 -1 +3
2 +3 -2
3 -2 *1
4 *1 +0
5 -10 -2

The goal of the game is to “process” the maximum number of integers. A new set is supplied by the game coordinator at each round. Using the above example, this means that in Round 1 player A will use -1 and player B will use +3 for all numbers supplied by the coordinator. Then in Round 2 +3 and -2 will be used, etc.

Each round consists of two ceremonies: Planning and Play. The ceremonies are time boxed to 5 minutes (this should be relative to group size, see more below).


During the planning the team reviews the previous round and decides how they will approaching the current play round. The team is also required to provide an estimate as to how many numbers they will process during this round.


During the play the team tries to process as many numbers as possible. Processing a number means applying the operation of every single participant, in sequence, to each number provided. Using the above example, if we are in Round 1 and the provided number is 20, then processing it would mean 20 – 1 + 3 = 22.


The following set of rules is provided to the participants:

  • Each individual operation is secret until the start of its respective Play portion of the round
  • All operations must be applied for the result to count
  • Order of operations is by participant’s legal first name (in sequence, on the previous result)
  • Each member of the team must participate during each round in Plan (desired) and Play (required)
  • The team decides everything within the rules

After making sure that everyone understood the rules, the game was started. I had 3 slides to explain the game, 1 with the sample of the email, 1 with the rules and 1 with a sample game played with 2 players. At the beginning everyone was provided with the list of participants sorted in alphabetical order. During run 2 (webex) a few collaboration tools were also suggested, in particular a collaborative editing and a collaborative drawing application.

I’ve also intentionally cheated when generating the operations (the ones sent out by email) by not including any operations where the order will matter. Participants only received additions, subtractions and multiplication by 1.

What was gained by participants (Achieved objectives)

In the following sections I provide a detailed list of what worked, what did not and why. Here I want to talk about the main objectives that were achieved by the game.

  • People who never worked together received a hands on demonstration that they can successfully organize to achieve the goal given little time, no help, direction, or up front organizational structure
  • Most groups went through complete failure first, had to iterate, and then used the lessons learned to get to the objective
  • People who never did Scrum like planning and retrospective ceremonies got to practice them on a real problem

Findings for Run 1 and 2

As I never had a chance to do a dry run I was not sure what to expect. Overall the game worked as desired. What was great was that the progression and the results were approximately the same for both in-house run and the webex run.

Some findings in no particular order for Run 1 and 2:

  • Both group were over 20 people
  • All groups started by trying to sort themselves in alphabetical order and having individuals perform their operation and then pass the number to the next person in the chain. This resulted in no numbers being processed correctly.
  • For both groups the second round produced little to no correct results, the algorithm was slightly improved over the above
  • No clear leaders emerged during the first two rounds, there was a quite a bit of not knowing “What are we doing”
  • On the second or third round both groups realized that it is better to somehow write down all the operations first.
  • Around third or fourth round both groups realized that they can detect quickly if the order of operations actually matters in each round. The webex group was more consistent as they were writing the operations in such a way that everyone could see them.
  • Both groups realized, in round 3 or 4, that if they can detect that the order of operations does not matter they can just combine all the operations first and then use a single person to apply them to all inputs.
  • Both groups picked up speed in round 4 but were making a lot of mistakes.
  • Both groups realized after round 4 that they need to have someone double check the results. With one group splitting up into a lot of smaller teams and another just having a single person double check.
  • In round 5 both groups were able to process and validate all inputs.
  • The webex group had an additional difficulty of picking and using a collaboration tool. While the selection was easy, at first much discussion happened around the best way to use the tool.
  • Only one of the groups was consistently providing estimates.
  • Both groups consistently ran over time allocated for Planning. I have extended it in a few rounds since the discussion was very constructive.
  • In both groups there was an emergence of leaders. Interestingly the webex group seemed to have developed only 1-2 leaders. In house group developed more, they led subsets of the group (not always with the most consistent result).
  • Due to a large number of people both groups had at first not taken some of the more effective suggestions.
  • Both groups ended up breaking the rule regarding revealing the operations only during Play, both revealed them during Plan. This did not end up making the problem any either for them due to group size, however please see below how the same affected a smaller group

Overall, the exercise felt enjoyable. People were very engaged and eager to get to a better result. Subsequent discussion of how they felt about the game and where they could improve was also productive.

Findings for Run 3

  • This group was about half as large as in Run 1 and 2
  • Two rules were relaxed 1. not revealing the operation before Play and 2. Not having each participant participate in both Plan and Play
  • The times were not adjusted relative to the size of the group, combined with the above rule bending the group went very quickly to just listing out all operations during Plan (there were only a few people=operations) and then immediately getting to the solution
  • It still took two rounds before the group became effective
  • As the result was reached very quickly, there was less “self-organizing” happening
  • People on the phone participated very little, which was quite the opposite to what happened in a fully remote group
  • Lesson 1: In smaller groups rules need to be more strictly enforced and times reduced.
  • Lesson 2: In mixed groups phone participation rule has to be enforced

Tool used

One initial difficulty I saw when imaging this game is how much would be involved in facilitating: generating emails with random operations, generating random numbers, providing the numbers, validating the results. To save myself some manual work I’ve ended up writing a very simple Access based tool that does all of this, provided you are using Outlook to send emails. I will share it here with the disclaimer that it was tested only to the extent described above.

I would be very curious to hear of your experiences running this game.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s