Moderator Instructions

This page gives instructions to the moderator, the one who is responsible for running the Classroom Mob Programming Game.

Prerequisites

It is assumed that students already have facility with a programming language, a development environment, and the fundamental techniques of Test-Driven Development.

The game is designed for teams of 4–5 players. You can play with larger groups, but it means you will have fewer iterations through the team.

Before the Game

Review all the rules so that you are comfortable with them and can moderate the experience.

Print up enough of the role handouts so that you will have one of each per player. These will need to be folded into quarters, which you can do ahead of time or have your players do themselves.

Determine how you want to arrange teams, the length of each turn, and how many rounds you want to complete. The recommendations are:

• Form teams of people the students do not normally work with.
• Make teams of 4–5 students.
• Use three-minute turns, which means a round should take at most 15 minutes. This allows you to fit two rounds, with brief retrospectives, in a 50-minute class period.

Choose the programming challenge for your game. FizzBuzz is recommended for novice teams, but other good examples include leap years, Roman numerals, or Pig Latin.

Getting started

Explain that the Mob Programming is a formalized way for small software development teams to collaborate on a project. The essential feature of Mob Programming is that the whole team works together on one problem at a time, and this ensures that everyone on the team understands the whole project. The goal of the game is for students to learn fundamentals of Mob Programming.

Set up the teams and, if possible, arrange the physical space so that each team has a clear workspace that includes table space, moveable chairs, and whiteboards.

Instruct teach team to select one laptop to use for the work session and to remove all others from the environment. If you are using a template project—either one from the main project page or your own—have them clone those repositories now.

Have each team write, on paper or the whiteboard, a list of the team members’ names.

Distribute the role handouts and explain that there are three roles in Mob Programming, and that at any time, a team will have one Driver and one Navigator, with everyone else being Mobbers.

Point out that each role gives you different actions you can take to earn experience points (XP). As the cards mention, you earn an XP when you take an action for your current role, announce it to the team, and mark a box. This is a good time to give a quick overview of each role to make sure everyone understands what the Level 0 actions are. Point out that when the boxes are all full, you level up.

Now, you can have the students annotate their list of team names with each person’s starting role. Label the first one as the Navigator and the second as the Driver, and explain that the rest are Mobbers. Explain how, each turn, the roles will process through the list of team members: that is, the second person becomes Navigator, the third person becomes Driver, and the rest become or remain Mobbers.

Present the programming challenge. There is a good opportunity here to frame the challenge within the context of the learning outcomes, for example, “Use Test-Driven Development and Mob Programming to solve the following programming challenge….” This can help prevent teams from falling into bad habits.

Prepare a timer that you can run for all players, and project this to the room if possible.

Now, you are ready to start the first round!

Running the Game

Give the signal for each team to begin playing and start the timer. When the timer goes off, remind the teams to process the roles down their lists. Mark down how many turns are remaining in the current round.

It can be helpful to circulate among the teams to help answer questions about the rules and help with technical problems that stymie student progress.

Between rounds, run a brief retrospective. There is not a single best way to run the retrospective, but depending on your observations, you might start with questions like these:

• What did you notice about the coding challenge or overall gameplay?
• Is there anything you are struggling with?

Ending the Game

Be sure to run a final retrospective so players can share their experiences.

If desired, you can have each team compute and share their score. A team’s score is equal to the sum of the highest levels earned by each student in each role. For example, if a team of four earned Level 2 in each of the three roles, then their final score is 6. Congratulate the team with the highest score. However, since some teams will try to maximize their score in a way that does not maximize their learning, it is not recommended to give any material or course credit awards for playing the game.

Variants

One Team

If you have few enough participants for a single team, then it is recommended to use a tool like Mobtime. It handles the timing and the role assignments.

Tournament Scoring

Another way to score the game is to score individuals rather than teams. This allows you to recognize the students who were the most successful Navigators, Drivers, and Mobbers. One advantage of this approach is that it provides an opportunity to discuss what made someone successful. A disadvantage is that it creates competition within teams as well as opportunities for collusion through dishonest play.

Larsen’s Mob Programming RPG

This work is based on Willem Larsen’s Mob Programming RPG. If you are looking for a larger game for more experienced developers, be sure to check it out.