Ball Runner: An Agile Game

The Ball Runner game originated from the #play14 unconference in London in September 2015. I was toying with the idea of a game around work in progress (WIP), which can be incredibly stressful for teams, and for individuals on these teams. I imagined a team playing a game in which one individual was bombarded with balls while trying to do something with them.

At the unconference, a few of us broke out to explore this idea. The result covers much more than my original intentions, but I believe the result is more useful. I’ve run this game a number of times and more recently at an Adventures with Agile meetup. The highest number of participants in this game is 20, but I hope that by sharing this information, others will be in a position to try it with a larger number of people in a big space.

Key takeaways

You can apply a few Agile principles to this game. Each facilitator will have his or her own take on these, and participants will also provide some additional inputs based on what they have learned.

Continuous improvement. In each round, the teams have the opportunity to inspect and adapt.
Self-organising teams. The game has no defined roles. (Well, there is one, but even this is not fixed to one individual for the whole game.) Teams are required to work together.
Challenge processes. Many teams in the early stages of Agile transformation are resistant to questioning existing rules and processes. This game will determine whether a team is willing to try to flex the rules to the breaking point.
Theory of constraints. As part of the improvements made in each round, the team should assess where the bottlenecks are in the system and look into shifting them.
Limiting WIP. Limiting the flow is one way to shift the bottlenecks, but a batch size of one is not always optimal. Some teams batch a large number of tasks between stages.
Push vs. pull. Some effective teams will look to model their flow this way: “pulling” from the final person in the group or from a previous bottleneck.
Kanban. Successful teams are able to visualize and communicate to each other the flow of the system.

Game details

Below is a summary of what you’ll need to play the Ball Runner game.

Players: Minimum 4; maximum is space dependent

Duration: 30 – 45 minutes

Objective: Teams are challenged to achieve a series of simple tasks with balls within two minutes. The more balls processed, the more value the team has delivered.

The initial run-through will quickly introduce bottlenecks, which will generate a large amount of WIP. Teams are given the opportunity to make several attempts to eliminate the bottlenecks, each time taking the opportunity to inspect and adapt. The rules allow experimentation and flexing of the rules to enable better performance.

Materials:

100 balls per team (really good teams may use all their balls in a single iteration, so either recycle or have some spares)
Five containers per team (boxes, bags, anything that can hold the number of balls)
A tool for recording scores on each team (e.g., a board, flip chart, or laptop and projector)
A timer or clock

Preparation:

A flip chart/board/slides that highlight the rules.
A flip chart/board/spreadsheet with a score table (Round/Estimate/Actual).
Divide the group into small, equally sized teams. Four to five people per team works best. Six is the maximum.
If you are playing with multiple teams, ask each team to name itself to foster competition.
Arrange the containers on the floor in a sequential line (simulates work flow), leaving room for people to move between the boxes. The more teams you have, the larger the space required.
Label the containers 1 through 5.
Put all the balls in container 1.

Goal:
Get as many balls as possible from container 1 to container 5 in less than 2 minutes.

Rules:

The same person must throw each ball high and catch it.
Container 2 can contain only those balls that were caught.
Each ball must be thrown between two people.
Container 3 can contain only balls that have been thrown between two people.
Except for the person in rule 7, each ball must orbit the team through a person’s hand. (“Orbit” means that the ball must go around the team through one person’s hand.)
Container 4 can contain only those balls that have orbited the team.
Only a single, designated person can place each ball in container 5 (“done”). This is analogous to a product owner signing off on the work.
Dropped balls are considered defects and are disqualified from being counted as done.
Between each round, teams will have two minutes to work to improve.

Facilitation:
Set up the space and read the rules to the teams.

Demonstrate the following work flow:

Take a ball from container 1.
Throw the ball high, catch it, and put it in container 2.
Take the ball from container 2, throw it to a person, ask them to throw it back, and put it in container 3.
Take the ball from container 3, walk around one of the teams and containers, and put it in container 4.
Take the ball from container 4 and put it in container 5, mentioning that the dedicated person can also perform other roles if the team decides it needs them.
If there are six members in a team, add a new rule whereby only a dedicated person can take a ball from container 1, similar to rule no. 5.

Get ready to play:

Confirm that the team understands the rules and answer any questions. There will be many, but emphasise that the only rules are those that have been mentioned.
Give the teams two minutes to organize themselves.
Within the two minutes, ask the team for an estimate of how many balls they think they can get through the system.

Play:

Begin the round, which should last only two minutes.
Tip:Watch for dropped balls, and collect them in container 1(time saver).
Count the balls delivered at the end.
Tip: Even if the team has counted already, count anyway. This gives the team a moment to catch its breath. Otherwise, the improvement time will be less effective.
Record the time on the score sheet.
Challenge the team to do better! Give them two minutes to improve, during which time you will need to ask for another estimate.
Repeat steps 1 through 4.
These rounds are essentially the same as the first. The teams will probably continue to ask for clarification of the rules and ask if they can do certain things outside of the rules.
Tip: By rule, the interim containers are not required. It should become obvious that one or more of these containers are serving no purpose. You might need to prompt a team to analyze the rules again; this is a key concept of the game. People assume that because the containers are there, they must use them.
If teams want to and time allows, then play another round or two.

Close:

Announce the scores.
Point out trends of observed improvement or good performance; what steps were taken to achieve the performance?
Were there any attempted changes that didn’t deliver improvement or affected performance?
Were changes evolutionary or revolutionary in nature?
Can the teams identify any principles or practices that emerged in the game that could be applied to their working lives?
Point out the key takeaways from the above.

This post appeared first on Scrum Alliance Member Articles blog

Ball Runner: An Agile Game