The Ball Point Game
When coaching scrum teams it is alway a good idea to combine theoretical teachings with some exercises that simulate what you’re teaching in a short time. When thinking of which exercises I could use to simulated the methodology, “The Ball Point Game” I’ve done in a training class by Boris Gloger many years ago came to my mind. The game had a prompt impact on me in regards of Scrum. The game simulates all the sprint ceremonies, such as planning, sprint, review and retrospective.
Preparation & pre-requisites
- The rules of the game (represents the Scrum Guide/Scrum rules). This you’ll need for explaining the rules to the team and also to put them on a wall visible for all participants during the game.
- Access to minimum 100 balls (representing user stories/backlog items). The only requirement for the ball is, that they can be passed from one person to the next. A cheap set of equally sized plastic ball are sufficient for a basic version of the game though. (In one my projects I was lucky to have a Kindergarden right beside the project office with lots of ball 🙂 )
- Two containers that can hold the balls.
- Flipchart to keep record of the teams achievements
- Timer/stopwatch
How The Ball Point Game works
The Ball Point Game simulates the scrum process with an autonomous team that adapts the process based on the rules and learnings. The default version of the game conducts 5 iterations (each with planning, sprint, review and retrospective) but could be shortened (minimum 3 iterations) or iterations added.
As with all exercises and game, first of all explain the game and the goal (process as many balls as possible) of the game. Then ensure the team understands the rules and make them visible to all participants:
- If you know this game, do not participate.
- 5 iterations, 2 minutes each
- 2 minutes (sprint) planning before each iteration incl. recording the team’s estimate on how many balls they will process
- record the number of balls the team processed per iteration and how many balls the team lost (that fell on the floor) on the flip chart -> sprint review
- Retrospective meeting after each iteration (write down improvements for the next iteration on the Flipchart)
- Each ball must be touched by each team member at least once
- Each ball must start and end with the same person -> Product owner
- Air time: When a ball is passed from one person to the next, it must have air time.
- Each ball successfully processed = 1 point
- Each ball that fell on the floor = -2 points
- A fallen ball is picked up and processed further successfully = 1 point
- keep time for each planning, iteration and retrospective -> timeboxes
Experiences
Normally the team start after a short discussion and passes the balls around (often trying to get more than one ball from one person to the next = high number of backlog items in progress). After the first iteration there will be a number of ball processed successfully. After 1 or two iterations you may remind the team that they can move freely through the location (as I’ve experienced teams that remained seated). The team will improve from iteration to iteration and also will take care of not letting too many balls fall or even pick them up again.
Before the fourth iteration you can tell the team that you’ve seen teams processing a lot more balls successfully (name a number higher than the teams achievement). In my experience this motivated the team to make further improvements and processes a higher number of balls than before.
Insights after fifth iteration
Reference the Flipchart (containing balls processed, ball that fell, learnings from retrospectives) and encourage a discussion amongst team members about the results right after the game. Ask them what they’ve learned from the game as well. After a few minutes follow up with some questions:
How did the team come to decisions?
As there is no team leader nor manager around the team self-organized and improved from iteration to iteration. This is a good example to let the team know that they decide how best to complete a task. Also encourage a short discussion on what would be different if there was a decision maker external to the team and the potential of all team members would have remained untapped.
Why do balls fallen down (=defects/bugs) cost 2 points?
As a defect or bug, all balls that fell on the floor must be processed, which is analog to defect fixing (which need to run through the whole process again).
How did the pace related to the results?
With each iteration the work went smoother or the team even had to work less. Team members stood closer together, reduced unnecessary movement (waste), or simplified tasks.
It’s important that the team realizes that they didn’t work faster to achieve better results or even that if the processed balls too fast, the produced defects (balls fell to the floor). The agile principle for that is: “Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”
What impact did input from the scrum master make?
After pointing out that you’ve seen teams processing many more balls than the team did after third iteration, stands for input from a scrum master to the team.
After I’ve participated and done the game with teams there are many more things I’ve observed and many more things that yo may observe. If so please share further learnings in comment section.
For variations of the game, such as influence of managers for example, you might find the post The Ball Point Game Variations useful. Scrum Master Learnings from The Ball Point Game is another post related to The Ball Point Game.
Reads:
Leave a Reply