Like many Scrum trainers, I use the Ball Point Game in my Certified ScrumMaster course. We do it fairly early on, in the first hour, before we`ve gotten know each other. I use the Ball Point Game to show teams that they in fact already know how to do Scrum, meaning they know how to use the inspect-and-adapt cycle to self-organize, set goals, and meet them. But I tell them another important reason for the exercise is to teach me something about the group that has come to my class. I look at how they solve problems together, how they innovate and how they deal with pressure, and this gives me clues to how I can help them learn what they will need to be successful with Scrum.

If you`ve never encountered the Ball Point Game, the rules are simple to grasp. In my version, the team is given a container of ping pong balls. Team members must pass the balls individually, with air time and without dropping them, through every person`s hand into the finish container. Balls that are dropped are "dead" and must go back to the start to be put back into play. Additionally, team members are not allowed to pass to the person on their immediate right or left. The objective of the exercise is to deliver as many "ball points" as possible in a two-minute iteration. Before each iteration, the team must commit to delivering a given number of ball points (this commitment is defined as the lowest number of ball points to which every person in the group agrees). The team goes through three iterations of the game, with planning/ retrospective sessions (also two minutes) in between.

The first thing I watch for is how the teams plan their first iteration. Some teams will have a "leader" who takes command and decides how to stand, who will be Starter/ Finisher, the number of ball points committed, etc. Other teams choose to "swarm" on the problem as a group, with nearly everyone contributing to the discussion as they decide how to approach the exercise. Still other teams don`t use the planning session at all, having little useful discussion about how they plan to meet the goal. In each case, I am seeing varying levels of ability to self-manage.

The next telling event is how a team approaches the second iteration. Armed with a bit of experience (having completed one iteration) I give them another two minutes to plan and make commitments for their second round. I emphasize that this is the time to make any process improvements they want or need.

Again, some teams use this time well and discuss improvements such as changing their standing positions, moving furniture out of the way or otherwise making it easier for them to accomplish their goal. Other teams have less productive discussion, with some team members shouting and arguing, while other individuals become "checked out".

Then it is time to make commitments for the second iteration. What I hope the team will do is use the concept of "yesterday`s weather" to do this. As the old saying goes: "Given no other information, the best predictor of today`s weather is yesterday`s weather". Likewise, given no other information, the best predictor of how many ball points a team can deliver in Iteration 2 is the number they delivered in the Iteration 1. I hope to see teams making this connection.

Even among teams that use "yesterday`s weather", there are telling variations. For example, two teams - Team A and Team B - might both achieve 40 ball points in the Iteration 1. Yet, in Iteration 2, Team A would commit to 46 ball points, while Team B might commit to 37. As I explain to my participants, both are using "yesterday`s weather" effectively. What the difference illustrates is comfort with risk. Many teams who commit conservatively (like Team B) work in industries or on projects where missing a commitment is disastrous (such as client projects with financial penalties for missing dates built into the contract). Other teams work in aggressive growth industries where pushing to stretch goals (like first-to-market) is most valuable, even if they are missed occasionally. The key to using "yesterday`s weather", in the Ball Point Game and in real projects, is to understand what level of risk supports the organization`s goals.

By the third iteration, most teams have developed an effective way to approach the Ball Point Game. Then it is time to throw in a wrinkle. After Iteration 3, I tell my team that they will be doing a "bonus round" in an attempt to "break the world record" for the most ball points ever. I write the number they must surpass on the whiteboard and give them a final two-minute planning meeting to decide how to achieve this goal.

In reality, the purpose of the Bonus Round is to take away the team`s ability to self-manage. After three iterations of setting and achieving their own goals, suddenly an outside entity (like, say, a manager) has upset the system by saying "You must achieve this goal simply because I want you to". Worse still, the "world record" number is completely fictitious and designed to seem, while not impossible, what I like to describe as "discouragingly large". To really seal the deal, I also "help" the team throughout the iteration by pretty much talking non-stop, cheering them on, urging them not to drop balls (a sure way to make people drop balls) and encouraging them to work faster.

Many teams fall apart completely during this time. They often get fewer ball points in the Bonus Round than they do in any of the other iterations. Wise teams do their best to ignore my constant talking - some will even tell me to shut up. But other teams will get sucked into my behavior and, when that happens, I soon have an entire team of people shouting excitedly and, ironically, dropping balls right and left.

One of the key lessons of the Ball Point Game is that teams work best when they are presented with a problem to solve and then given the autonomy to solve it the best way they can - in other words, when they self-manage. Removing that level of control reduces commitment level and therefore performance. Perhaps the most dramatic example of this came from a class I did a few weeks ago. The group produced this result in the Ball Point Game:

	Committed	Delivered
Iteration #1	0	25
Iteration #2	20	63
Iteration #3	60	98
Bonus Round	137	DNF

As you can see, this team exhibited a number of interesting characteristics. First, as a group, they are "conservative committers", to the point where they were so unsure of expectations in the first iteration they were not willing to commit to delivering any ball points. Still, they had good success and by the third iteration were delivering a large number of ball points. Then came the Bonus Round. As with many teams, this new complication threw their self-management into disarray. But with this team, it was a disruption from which they could not recover. They struggled with so many innovations being introduced at once in a frantic effort to achieve the "goal" that they were not able to deliver even one ball point. My recommendation to this team as we de-briefed after the exercise is that they should wholeheartedly pursue Scrum because it was clear from the exercise that they worked best under a system of self-management.

In Scrum training, the Ball Point Game serves as a wonderful learning opportunity for student and teacher alike. It shows teams that they already know the basic tenants of Scrum, meaning how to self-manage and make incremental improvements through the inspect-and-adapt process. And as an instructor, it gives me an illuminating view into the individuals who have come to my class, how they solve problems and their willingness to embrace self-direction.