It is always nice to learn through play. The lean tennis ball game, also called the lean point game, is a simple exercise that can be used to explain the PDCA cycle (Plan - do - check - act) or "agile".  It is also a great game to use as warm-up exercise at the start of a workshop since it gives instant interaction. But more over it gives instant fun! In short, the lean tennis ball game is the ideal ice-breaker.

The lean tennis  ball game is one of the oldest games, but it is still very relevant.  The groups with which I played the game always give positive feedback. It teach you how to work in teams and continous improve.

The great thing about the lean ball game is that you can do it with large groups. I have played it with large groups of 50 people without a problem.

Why playing the lean tennis ball point game

You can discuss lean and/or agile as long as you want or you can simply try it yourself! Learning by doing has a lot of advantages.  Learning by doing gets people involved, and motivates them to  connect what has learnt with what is experienced. In other words, it makes the learning meaningful.

The purpose of the lean tennis ball point game

The goal of the game is to pass as many balls as you can  in two minutes. Tennis balls are usually used for this, but you can also use other balls such as ping-pong balls. 

Tip: You can form several groups so that there is some competition.

Preparation for the lean tennis ball game

This is what you need:

• 100 balls per group
• 2 collection bins per group (1 for the balls that still need to be introduced in the process and one for the balls that have gone through the process)
• whiteboard/ flipchart

Rules and game play

You need to have enough space to play the game. If the weather is nice, you can even do this outside! Have the group designate one player as the starter. It is his/her responsibility to bring the balls into the process. The rules are simple:

• Everyone is part of one big team.
• Only the starter can start a new ball. He is also the only person who can put the ball in the destination basket. So every ball must end where it started.
• Each ball must have air-time (two persons can not touch the ball at the same time) .
• Each ball must be touched by every team member.
• Balls cannot be passed to your direct left or right neighbors
• Any ball that falls on the floor or does not respect the rules is a defect

I always write down the rules on the flipchart so that teams can look at them again when discussing a strategy. If people ask you any more questions about the rules, just tell them that all they need to know is written down in the rules on the flipchart.

You can  play several rounds. I recommend playing 5 rounds. But you can play anywhere between 3 and 10 rounds depending on how much time you have for the game. At the start of each round (sprint/iteration), the team should estimate how many balls they can play around. After the round (sprint/iteration), it is noted how many balls were achieved. Then the result is discussed.  How did we do it. what went well? What didn't go well? And how can we do better?

Planning for the lean tennis ball game

The following planning can be used:

• 2 minutes: discuss the strategy to be followed and write down an estimation of how many balls the team will pass.
• 2 minutes: play the game for 2 minutes and write down how many balls the team passed.
• 1 minute: determine the strategy of the next sprint/iteration. Write down what the team has decided to change.

Let them know when a minute has passed and count down the last 10 seconds of each step. You can rise the time of the last step to two minutes depending on the size of the team and how well they can handle pressure.

Score

On a whiteboard or flipchart, keep track of the score for each round. Note both the estimated number of balls and the number of balls achieved.

You can also keep track of the number of defects (these are the number of balls that fell on the floor or where the rules were not followed).   If you do not want to count them (sometimes they are hard to find and you will lose a lot of time) you can illustrate the trend by using emoticons or other symbols or signs (for example: ---, --, - , + , ++ , +++).

The easiest is to make a graph as below. If you have several teams you can use several colors to distinguish between the teams' entries.

The world record if 159 balls in 2 minutes, so if your team is verry ambitious make sure to have enough balls 😊.

Lesson learned

Let’s take a look at the numbers. Hopefully we did improve. Did the estimates also improve? And did we get less defects?

There are several lessons learned you can take away from the lean tennis ball game.  Since there are several parallels you can make with agile or lean.

• Self-organization is key. It is interesting to see from where the leadership comes if you do not have a appointed leader. Often ideas are generated by the whole team since they all feel empowered.
• Fail fast, fail often! It is okay to fail. it is okay if an iteration does not give an improvement. You can learn also from failures.
• Do not spent to much time on planning and brainstorming on ideas. You often learn more from first hand experiences than from long brainstorm sessions.
• Note that the teams where not disturbed during the game with other tasks, therefore they could achieve fast good results. The shared a common goal.
• All processes have a natural velocity. Don’t try to reach more output by working harder. Work smarter not harder. You have to come up with good ideas to reduce the waste in the process and increase the output.
• You do not throw a ball to somebody who is not ready. This is similar to pull in lean.
• The game shows the idea of sprints or iterations, where the team uses repeatably the agile cycle plan, design, develop, test, deploy ,review & launch.
• The game also shows the idea of the PDCA cycle: Plan do check act

But don’t just summarize the learning points let the team come up with them. You can ask the questions below to your team to let them come up with the lessons learned.

• What went well? What worked?
• What did not went well? What did not work?
• How did you organize yourself?
• Was there a leader?
• Where did leadership come from and in which style?
• Were improvements achieved by working harder or faster?
• Why did the estimates improve (or not improve)?
• Why did the defects decrease (or not decrease)?
• What were the bottlenecks in the process?
• How did the starter feel? (he is normally the bottleneck).
• How did it feel to work in iterations?
• Did some iterations fail?
• How did you improve?
• How was the communication within the team?
• Would it have helped if we did less iteration and more preparation?
• Would it have helped if we had documented the process in more detail?
• Which elements can you take over into your everyday work?

Please note that you can make lessons learned on several of  The Four Values of The Agile Manifesto and The Twelve Agile Manifesto Principles  from this game:

• individuals and interactions over processes and tools
• working (software) processes over comprehensive documentation
• responding to change over following a plan
• Frequent delivery of working (software) processes
• Support, trust, and motivate the people involved
• Enable face-to-face interactions
• Working (software) processes is the primary measure of progress
• Agile processes to support a consistent development pace

• simplicity (the simplest solution often works best)
• self-organizing teams encourage great architectures, requirements, and designs

• Regular reflections on how to become more effective 
• …

Have fun!