Agile scrum training: the ball exercise

Agile scrum training: the ball exercise

A few weeks ago, aFrogleap celebrated its 5th anniversary with a fair and a party for clients and friends. During the fair, we had several so called stations to show aspects of the work we do. Together with Naos, I organised a little game to introduce novice people to the scrum flow, based on the description as it was once blogged by Boris Gloger. Since the game was well received, I’ll outline the rules and share them with you in order to give you scrum adepts another tool in explaining scrum in a playful manner.

Ball game ingredients

To play this game, you will need the following things:

  • Sufficient space
  • 4-8 participants
  • As many balls as participants (tennis ball size, coloured)
  • Something to track time
  • A few large sheets of paper on the wall
  • Some sharpies to write on those pieces of paper
  • About 20 minutes

The rules

The rules to this game are pretty simple: pass the balls around the group as many times as possible within the set time. Every ball that has been around the whole group accounts for a single point, and at the end of an iteration, all those points are added up and noted down. It’s good to have five rounds of iterations. Before an iteration starts, the group briefly discusses how they plan to do the iteration and they give an estimate for the amount of points they can score.

Put these constraints on the wall for your team, as you want to make sure that everybody works with the same constraints/rules:

  • You are one team: everybody in the room participates.
  • Ball must have air-time.
  • You can’t play the ball to your direct neighbor.
  • Start Point = End Point.

The playbook

On another sheet of paper, note the schedule while you explain the activity to the participants:

  • 2 minutes introduction
  • 2 minutes for rules
  • 2 minutes preparation time for first iteration

Also, include the process for an iteration, which will be the same for all 5 iterations:

  • Get a point estimate from the team
  • 2 minutes per iteration
  • 1 min team to plan improvements
  • 5 iterations

Close with a 10 minute debrief where you discuss the learnings from the team.

Finally, draw a table where you can note down the point estimates and actual points, along with some short notes that came out of the time spent on the planned improvements. When you are done with this, your team is ready to start!

Playing the game

Now it’s time to play the game. Explain the participants once more what the rules are, and start their time-boxed slot to prepare for their first iteration. Make sure to be strict in keeping time. After the two minutes have passed, ask for the point estimate the team thinks it can achieve, then start the iteration.

You’ll notice that the team will struggle a bit at first to get going: estimates might be too high (or low), the process needs tweaking, etc. After a few iterations, they might get the hang of it and will start to make better estimations and gather more points.

The variations

When the game is a few rounds in, during the improvement process, you can mention that previous teams were able to reach a much higher score per round, and that you are somewhat disappointed in the achieved score. Depending on the score picked, this might lead to either a demotivated team (“We’ll never reach that score, why bother trying to improve only marginally?”) or to a motivated team that will look for ways to think differently about the process they are using to reach their goal (“There must be something we can drastically improve!”). If the target seems within range, the team might show a significant improvement in their results in the next round. Use this as a topic in the debrief discussion: what happened? Why was it suddenly possible to break the believed optimum?

Another variation is to introduce a constraint to the team, like taping the hands of one of the participants to each other. This might introduce a new way of looking at how the team works to achieve their goal (“We can also use our hands as cups, this might speed up scoring points”).

Finally, there is the variation where you introduce a manager to the game. If you are going to use this variation, do it at the very first iteration. Explain that you are the manager, and that you are going to feed the balls to the team. This variation introduces a step that is wasteful and not needed to the process. If the team asks you to stop feeding the balls to the team, simply agree to do so. You can do whatever they ask you to help you with if they may ask. Some teams will never question your ‘help’ in the process, usually because they consider the manager as a authority figure. While reflecting after the iterations, ask how the team felt about the role of the manager and how he pushed work into the team. Why did they not challenge his help? Discuss with your team how to challenge authority in order to make a team more effective in reaching their goal.

The debrief

Now that the team is done with the ball game, it is time to discuss how they experienced it and how it fits with past experiences. Here are some questions you can ask to facilitate the discussion. Make sure you ask them in an open ended format:

  • What iteration felt best? Why?
  • Was there a point where you made significant progress? What caused this progress?
  • If you would have had 8 minutes to plan an iteration, what do you think you would have achieved?
  • How do you think the way you communicated as a team (face to face) impacted the cooperation? Could the improvements have been achieved when you would have worked over a distance (through phone or email)?
  • Would it have helped if someone would have been a lot better at this game than the rest of the team?
  • Who had all the ideas?
  • What role did you take in the team?
  • When something went wrong, what did you do?

After the debrief, ask your team if there is anything they can take back into their work from this game. Note down any points on the sheets of paper.

Happy ball tossing!

Wanna know more about the benefits of Scrum? In 2016, we moved from from project-based teams to Scrum teams. Here's what we learned in the process.