The ball point game by Boris Gloger is a great game for introducing Scrum to new agile teams. I have played and facilitated this game a few times and would like to share my notes. Many thanks to Boris for creating this game. Special thanks to Henrik Kniberg and Robyn Dymond for facilitating and sharing their ideas on the game at AYE 2009.
The point of this game is to pass as many balls as possible through every team member in 2 minutes. The team gets a point for each ball passed through every member of the team provided that the first person to touch that ball is also the last. There are 5 iterations. Before each iteration the team estimates how many they think they will pass. At the end of each iteration the actual number passed is recorded.
The rules are explained and the following should be written on a flip-chart:
- You are one big team
- Ball must have air-time
- No ball to your direct neighbour
- Start Point = End Point
- Iteration = 2 min
- In between = 1 min
- We play 5 iterations
Create a flip chart with the “playbook” for the game:
- 2 min introduction
- 2 min for rules
- 2 min preparation time for first sprint
- Run 5 iterations:
– Get an estimate from the team
– 2 min iteration
– 1 min team to plan improvements
- 10 minute debrief
Write the rules on a flip chart or white board.
Bring a box of balls – Boris recommends tennis balls. I bought 50 practice golf balls and use them.
Prepare a flip chart sheet or whiteboard to record the team results on each iteration:
Make sure there is an open space sufficient for the team to arrange themselves in a circle.
Make sure you have an open flip chart or whiteboard with markers to record the score and for debrief.
You will be asked things like can we “do such and such?”. When such questions arise, respond by pointing to the rules and saying “It’s your process”.
Ask the team and record the key changes the team made on each iteration in the ‘Notes’ column of the playbook. This will help in the debrief as the team is able to look back and see the changes they tried and the results they achieved.
Often their will be balls over the place. I have found it better to only start the 1 minute retrospective timing after all the balls have been picked up so that the team can fully focus on improvements for the next round.
Add a Manager
I learned this variation from Robyn Dymond. After introducing the game and rules, state that you will be the manager and will feed the balls to the team. The intent is to add a process step that is unnecessary and wasteful. If they ask you to stop doing this simply agree. In fact, do anything, beyond passing balls, to help them if they ask. Do this before the first iteration if you are going to do this. Some teams will never question your ‘help’ and then when debriefing you can ask how they felt about having work pushed at them. You can then ask why they did not challenge your help and they will often say that you are an authority figure. This may open the door to discussing challenging authority and asking managers for help.
Set a Constraint
Jeff Patton told me how we sometimes uses painters tape to tape the hands of one of the participants. And often this constraint, can lead to an aha moment where the team realizes that if they cup their hands they can pass more balls. This could lead to a discussion of how constraints can sometimes breed innovation.
Set a Stretch Goal
Usually after 3 iterations you should see some significant improvement and they may feel that they have reached an optimum level. At this time say something like “I performed this exercise with another team that achieved 200 points”. Most often, the team will have a significant improvement and you can debrief on how the team can achieve significant improvements when they set aside what they feel is their limit.
Set an Impossible Goal in a Bonus Round
Tom Reynolds in his notes on the game describes a variation suggested to him by Angela Druckman. At the end a bonus round is introduced with an impossible target – significantly larger than the team’s best iteration. You may want to say something like “The world record for this is 350. Let’s see if you can beat this record – I think you can!”. I suggest not doing this with the Stretch Goal as it may result in confusion.
Henrik Kniberg suggested that when the game is over he sometimes asks someone to throw a business card as far as they can. He suggests having doing it a few times and putting pressure on them by saying things like “Come on, I know you can do better than that!”. The perhaps not so obvious step is to scrunch the card up and throw it. However, I did have someone how was very adept at flicking cards and was able to flick a card more than 15 metres! The point is that even just after the learning from the ball point game we may still have trouble stepping back and looking at the process and seeing improvements. Most people, will initially just try to throw the card harder! Becoming a learning team takes time and practice!
Ask with an open question and allow people to share their experiences. I then guide the remainder of the debrief around the remaining points depending on what I noticed, team interest, and time.
What Iteration Felt the Best?
Ask what made that one feel best? Why?
Look for an iteration where there was a dramatic improvement due to a reorganization. Ask whether this improvement was due to working faster or harder. Point out that every system has a natural velocity and that to significantly improve the system requires changing the process.
Deming – Scrum ‘Inspect and Adapt’
Draw parallels between the game, Deming and SCRUM:
|Plan||Estimate||Sprint planning – estimate velocity|
|Do||2 minute iteration||Sprint|
|Study, Act||1 minute improvement||Sprint retrospective|
You may also want to show that this parallels the Scientific Method.
Theory of Constraints
Ask if there is a bottleneck in the system and if so where it was. Ask how they identified and whether they attempted to address it. Ask if it would be helpful to improve efficiency at a point other than the bottleneck.
Experiments Sometimes Fail
Often a team will try something that will not result in an improvement and performance may actually drop. Point out that this is ok and expected. Sometimes we try a good idea and it does not work out. We don’t have to get it right every time and we learn more from our failures.
If you acted as the manager and this was not challenged then ask why they did not challenge this. Point out that is was not a rule and that we must be careful to challenge constraints and identify waste if we are to achieve maximum performance. Negotiate with your management and customers – we all win!
Most teams will put in place a system where the balls are not passed until the downstream person is ready – i.e. a pull system. When balls are pushed it usually results in dropped balls and lack of flow. Point out how a pull system maximizes flow and increases performance.
Rhythm and Flow
Do you experience a rhythm? Point out that flow will happen if:
- the challenge is doable
- people are not disturbed during the iteration
- the work has meaning
You may want to point out that agile development has multiple levels of rhythm: daily standups, sprints, releases.
The Power of the Retrospective
Ask them if they had 6 minutes (total planning time) to plan for a single 2 minute run do they think they would have achieved the same results?
The Power of Face to Face Communications
Could the same improvements have been achieved via phone or email? Would it have helped to document the process?
Would it have helped if someone on the team was much better at this game than the rest of the team?
Whole Team and Leadership
You may notice some good suggestions were made but not followed. Ask the person how that felt. Is there a natural leadership model on the team? Is there a “right” leadership model? A post on Babble burble banter balderdash suggests asking the following questions:
- Who had all the ideas?
- What roles did you all take?
- When something went wrong what did you do?
If you introduce a stretch goal after the third iteration ask how that felt and the impact it had. Often, teams will perform better knowing that improvements are possible. And improvements are always possible!
According to Kane Mar setting an impossible goal often results in decreased performance.
How Does this Apply to Us?
Close the game by ask the team if there is anything they can take back into their development team. Record on a flipchart.