In the middle of 2011, one of the Scrum coaches at the organization I was then working for approached the ScrumMasters and suggested we try playing a game he coined "Scrum Monopoly."1
He had come across a paper by Darin Cummins entitled "Using Competition to Build a Stronger Team." While this article does not actually talk about the board game, it does talk about earning and spending money as part of a game.2
The coach went through the basic idea with the ScrumMasters. I then expanded on the idea and introduced it first to one of my teams, then to the others. In 2013, while working on my current contract with a different organization, I also introduced it to one of my current teams.
Taking the bare bones of the idea, the following building blocks were put in place:
The ScrumMaster acts as the banker and referee, and so does not play the game.
Each team member receives £200 of Monopoly money at the beginning of a sprint.
Then team members "earn" money for certain behaviors, like turning up on time to the daily stand-up.
Team members are encouraged to give each other Monopoly money as a thank-you for help received.
A random element is introduced to ensure that everyone has different amounts of money at the end of the sprint.
An auction of items is held at the end of each sprint, after which all leftover Monopoly money is gathered back in and everyone starts from the same place at the start of the next sprint.
The first incarnation of "Scrum Monopoly"
As preparation for playing, we purchased toy money that the team members would earn during the game. This would give the team members tangible money to hold onto. I then put together some Chance and Community Chest cards to provide the random element. I based these on a mix of "real" Chance and Community Chest cards, made-up cards designed to help drive good Agile behaviors, and some purely fun cards. In general I tried to make the Community Chest cards be about the team and the Chance cards about the individual.3
I made sure the cards were printed in color and had them laminated. This way they endured longer and I could shuffle them between sprints. The shuffling meant no one knew what to expect by engaging in "card counting."
Starting to play
Speaking as someone with a sometimes "goldfish memory," I only gave out the £200 for passing Go once. So, after the first sprint of playing, team members had to earn money and not start with a pot of £200. No one ever complained about this, and I feel it did cut down a bit on the admin side.
I would give a random sum of money (one day it could be £500, another it could be £50) to those who turned up to the stand-up meeting on time. Latecomers either got a reduced amount or none at all, depending on how late they were.4
The amount given varied so that team members could not calculate how much they would lose if they did not attend or were late.
At the end of each stand-up, I would ask a team member to pick a Chance or Community Chest card. I tried to pick a different team member each time but did not use a set order of choosing the person, thus maintaining the randomness.
The end-of-sprint auction was held after the sprint retrospective, for which I purchased some inexpensive items totaling no more than £10. I acted as the auctioneer, as I have enough daftness in me to be comfortable with "playing" the auctioneer.
Effects of play
It was interesting to observe how the game changed some behaviors and could also change the mood of the team. The following are some of the effects of playing the game:
What didn't work
The random amount paid for attending the stand-ups definitely had the desired effect of encouraging team members to be more punctual, even if they only made it by the skin of their teeth.
I also found that I could let them know more effectively if I was displeased by something. For example, I had been asking them to fill in a spreadsheet of the number of hours they were pulled off to work on other projects or BAU. They weren't doing it very well until the morning I gave them all just £1 for turning up to stand-up. I explained I was unhappy by their failure to provide the information. I never had to remind them again. They wanted more than £1!
It soon became apparent that not all cultures are familiar with the game of Monopoly. So they had no concept of what Community Chest and Chance cards were about. I discovered that it was easier to refer to the cards as Pink or Yellow.
The choosing of the card was a lot of fun, as the team member who picked never knew if it would prove to be "good" or "bad" for them. It usually produced laughter, ending the stand-up on a light, upbeat note.
Whether it's because of cultural, platform-driven, or company-culture reasons, the team members were clearly not used to being able to have fun at work. Introducing this element proved to be very popular.5
One of the behaviors hoped for when we started out didn't happen. This was the concept of team members gifting each other money for help they had received. Occasionally a team member would do this, but on the whole they became quite competitive about the amount of money they could accumulate and so didn't like giving it away.
This did not have a detrimental effect on their actually helping each other with work. It seems that helping each other is either altruistic or more driven by the team attaining its commitment rather than gain in the game.
Variations on the game
Money for tasks
As we went through our sprints, we made a couple of changes to the way we played.
The first variation was instigated by our PO, who was getting a bit frustrated by tasks taking a long time to move from In Progress to Done. He started putting some of his money against a task that he thought should be moved to Done more quickly.
So I tried a variation in which, instead of money given out for attending the daily stand-up, money would be put against tasks in progress (actually physically on the board). If the task didn't move to Done within a reasonable timescale (usually by the next stand-up), the money was removed and the owner of the task didn't get anything. If they had a good reason, they could get a reduced amount.
After a while I abandoned this variation, as it could become quite depressing for individual members and so didn't really encourage good teamwork. I guess in a team where teamwork was actually better ingrained, it might work better. But, at this organization, there wasn't really a culture of "the team" and it was difficult to install. So I wouldn't totally discount using this variation again, with caution and in a different team -- but it is unlikely that I would use it.
Money for tasks done
Another type of "money for tasks" I tried was to give additional money (additional to that given for attending stand-up) to individuals when they moved a task to Done. This is different because it doesn't matter how long the task has taken to get to Done. It is simply a reward for getting there. The team also developed a habit of cheering when a sticky note got moved to Done. This proved to be quite popular, and so we continued with this variation.
Playing with mainly offshore team members
One of my teams had a large proportion of permanently offshore members. It didn't seem fair that they would not be able to join in the auction properly, but we couldn't justify spending money on shipping items to India or South Africa. So initially I decided not to play Scrum Monopoly with that team.
However, one of the offshore team members who had played Scrum Monopoly with one of my other teams (while he was onshore) brought up in the retrospective that he wanted to play the game. The other team members agreed.
So I held a brainstorming session with some offshore team members, a couple of coaches, and another ScrumMaster to see if we could come up with a workable alternative to the auction.
We narrowed it down to a couple of options and let the team vote on which we would use. They chose that whoever had the most money/points would be able to choose one or two tasks for another team member to perform.6
The tasks chosen were normally something simple, like taking a photo of them at their desk so we could see where they worked, or singing a song everyone could hear.
These "tasks" proved to be very popular and generated a lot of fun and laughter for the team.
Change of auction rules
In the beginning, as one person was buying the auction items (me), I soon ran out of ideas about what items to buy. So I changed the auction rules so that everyone in the team brought in an item or two.7
This led to a wide range of auction items, although those who thought about it at the last moment usually bought chocolate. Chocolate always went down well, though, and was usually shared among the whole team. This shows that the fun of the auction is more important than the auction items themselves. In fact on one occasion, in order to have something nonedible, I auctioned off a piece of tinsel that was a leftover Christmas decoration. It subsequently adorned the desk of the team member who bought it! People did compete with each other over certain items, but they would also donate money to someone who didn't have enough for an item they wanted.
You must remember at all times that the team is trying to achieve a goal as a team, and not individuals, and so you must be careful that all members of the team are seen to be being treated fairly in playing Scrum Monopoly.
In order for the game to work, the rewards have to be attainable. Likewise, any "punishments" used must not make the team members despondent. This is why the "money for tasks" variation didn't work very well. I prefer to encourage improvement with a positive approach rather than a negative approach.
You have to be alert to the fact that some team members can start behaving selfishly in trying to gain as much money as possible. I believe we mitigated this risk by using low-value items in the auction.
The second incarnation
In the second organization where I have played the game, it has also been met with enthusiasm. I have also introduced a new element to the game:
I observed that this particular team (as with many teams, I suspect) had a bit of a downturn on a Friday. So I introduced a Friday Challenge. For this I take a close look at where we are on a Thursday afternoon or Friday morning. I then decide on what stories can be moved to Done or how many points can be achieved by end of play on Friday, if the team puts their collective mind to it. I then tell the team that if they achieve the Friday Challenge they will receive a reward. Usually this is in the form of extra "money," e.g., sometimes everyone gets an extra £100 for every story done, or I may give everyone an extra £500 if we reach a certain number of points achieved. The Friday Challenge can be used on its own without playing Scrum Monopoly -- make up your own reward. I can't stress enough, though, that it has to be achievable or it won't work.
In this organization I also have an offshore team. They also play the game using points instead of money, and we give the team member who has the most points at the end of a sprint the honor of being "Employee of the Sprint" along with a simple certificate. I think this underlines again that the rewards do not have to be great.
Bringing a bit of fun into the workplace can raise energy levels and help increase a team's teamwork and velocity. In fact, the team members themselves have stated that the Friday Challenge has helped them increase their average velocity.
You do have to be wary of any negativity and nip that in the bud. However, overall I hope many of you will give some form of this game a go and see how it affects your teams. It would be good to know how you get on if you do try it.
I am aware there may be copyright issues with using this term, but it stuck in the teams I worked with and so I cautiously use it here. No infringement of copyright is intended.
There are distinct differences between what I did and what Darin did in his paper.
Interestingly, only one of the team members worked this out, and then only at the end of the project.
Lateness to stand-up was an issue with this team, and the game really did help alleviate the problem.
In fact, when my manager requested that I stop playing after a few sprints in order for it not to go stale, my teams made it clear that they loved playing so much they did not want to stop. So, we continued through the whole project.
The tasks could be vetoed by the ScrumMaster if they were deemed inappropriate.
Always low value.