Agile Games - Ball Point Game

With my companies developer conference coming up I wanted to find some fun games to illustrate some of the advantages of Agile methods and SCRUM to those not yet invested. During my SCRUM Master training I found the physical learning very beneficial.

One of the games I played and found detailed on the internet is the "ball point" game.

The setup

The game itself is pretty simple. You need a bunch of objects to pass from one person to another. The recommended object is a ball but which type of ball depends upon what is available to you. Tennis balls are good. If you can get half of the balls in one color and the other half in another that may help but it is not required. You will need 20 or so more balls than people in the group. Unless you like running around I would suggest one or two containers big enough to hold all the balls be available.

You will need plenty of room. Enough for all the players to stand in a circle.

You will need a white board or flip chart to record the scores.

You will need a timer, a smart phone will be fine.

The aim of the game is to pass as many balls as possible in the time allowed from one player to another until every player has touched the ball. The ball then scores. The time allowed is 2 minutes and you will get 5 goes. Before each go the team have 1 minute to plan their approach and give an estimate for the number of points they can score and note any significant changes to the process. At the end of the go record the actual number of ball points scored and any balls dropped.

The rules

Write the rules on a flip chart visible to all. These are the only constraints of the game.

1. You are one big team
2. The ball must have "air-time". It cannot be passed directly from hand to hand.
3. No ball can be passed to your direct neighbor
4. The Start point is the same as the end point
5. If you drop a ball it is out of the game
6. Each go, or iteration, lasts for 2 minutes
7. You have 1 minute between goes to plan
8. There will be 5 goes or iterations 

The impossible target

After the fifth iteration say that you have seen a team achieve 150% more points. Does this team think they can do that? ... 

What we take away

That we are following a Deming Cycle - Plan, Do, Check, Act much like SCRUM. With each iteration we learn and use that leaning to improve.

Depending upon the approaches taken we may learn that too much work in the system leads to mistakes, dropped balls, and is less efficient.

That communicating together as a group face to face allows us to rapidly adapt the process for quick improvements. Imagine if the planning/checking phase were done using e-mail?

What if we had a "star" player? Would we have scored more points?

During the impossible target round we should see the team fail. Either they will be stuck in the planning phase past the minute or they will leap into the task without proper planning leading to dropped balls. This teaches us that unrealistic goals lead to chaos and lack of planning and team work will reduce quality. Did the team have a clear agreement of what their process was before starting?

Did the team achieve "flow"? A state where everything was running nice and smooth and the points were flowing. How does the team think interruptions might have impacted the flow? 

Links

With a twist - unrealistic goal set

A more detailed explanation