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

Agile Games - The Penny 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 described on the internet is the "Penny Game". I thought I would record it here so I can share with the other SCRUM Masters in my organisation.

The setup

The requirements for the game are pretty simple. You need 20 coins. The values are not important but 80% of the total value should be held by 5 of the coins. If possible try not to make the high value coins too different from the others. If they are gold and the others bronze it will give the game away. This make up of values will be used later to illustrate a point. You will need a whiteboard or flip chart to write the results on. A piece of paper will do at a pinch.

You need 7 players.

1. The customer - his role is to collect the output of the process. The deliverable of coins.
2. The manager - his role is to write the results up and to time the process.
3. 4 team members - their role is to act as workstations.
4. SCRUM master - to facilitate the process and guide the team (this is your role)

The Game

The game is simple in nature. The coins are fed into the system by the manager in various ways described below. Each workstation turns each of the coins over if you are working on tables or flips them in turn if you must stand. They then pass the coins to the next workstation until all coins have been processed and the final station passes them to the customer. The manager times this from the point he hands over the coins to the first station till the point the customer shouts stop. The manager then writes the cycle number and the time on the white board or flip chart.

First Game Cycle

Each worker should sit apart on different desks within the room. If standing then they should stand apart with as much distance between them as possible. Explain that once they have processed the coins they must carry the coins to the next workstation and return to their original position before the next worker can begin the task.

Begin the game with the manager giving all 20 coins to the first workstation.

This is the baseline time. It should be the worst time.

Once the game has finished the SCRUM master conduct a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did and what one improvement could be made to get a better time. I would anticipate that change will be in the list of other cycles below so make that one change and proceed with that cycle.

Co-located Game Cycle

Each worker should sit or stand next to each other so the time to transfer coins from one station to the next is reduced.

Begin the game with the manager giving the last used count of coins to the first workstation. If this is the second cycle this will be 20 but the game may run out of order, which is fine.

The time will be quicker than the previous cycle because we have taken out some process time. The time to travel between workstations.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle. They will understand that removing the travel between workstations reduces the cycle time.

Make the point that the travel time between workstations represented a communications delay. Removing communications delays by co-locating the team reduces cycle times.

Ask the team what one improvement could be made to get a better time. If they have no suggestions of their own steer them towards varying the batch sizes. 5 is the ideal batch size but it may take some cycles to get there.

Reduced Batch Size Game Cycle

When they have decided on a batch size start the game. The manager feeds in the batch size of coins to the first workstation. Once that workstation has passed the coins to the next the manager adds another batch. The time begins after the first batch is in the system and ends when the customer has all the coins.

The time will be quicker than previous cycles and probably quickest with a batch size of 5 because we have improved the process flow. Other team members do not have to wait so long for work and we get more done in parallel.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle. They will understand that reducing the batch size makes the process more efficient.

Make the point that reducing the size of the work allows each worker to be working on something sooner. The improved flow of work through the team makes them more efficient.

Ask the team what one improvement could be made to get a better time. Ask them what if the customer would be happy to accept delivery of some of the functionality to test with the understanding that the rest of the functionality will follow?

Reduced Batch Size Game Cycle

When they have decided on a batch size start the game. The manager feeds in the batch size of coins to the first workstation. Once that workstation has passed the coins to the next the manager adds another batch. The time begins after the first batch is in the system and ends when the customer has all the coins.

The time will be quicker than previous cycles and probably quickest with a batch size of 5 because we have improved the process flow. Other team members do not have to wait so long for work and we get more done in parallel.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle. They will understand that reducing the batch size makes the process more efficient.

Make the point that reducing the size of the work allows each worker to be working on something sooner. The improved flow of work through the team makes them more efficient.

Ask the team what one improvement could be made to get a better time. Ask them what if the customer would be happy to accept delivery of some of the functionality to test with the understanding that the rest of the functionality will follow?

SCRUM Team Game Cycle

For this variation of the game the manager gives each team member an equal share of the coins. The timer starts when the manager shouts go and each team member turns over their coins. The game ends when every team member has raised their hand to indicate they are complete. 

The total time will be the fastest so far. Only the 80/20 game variation with a SCRUM team will be faster.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle? It should be clear to all that the whole team working together is faster than the 'waterfall' like process of passing coins from one worker to another.

Ask the customer if he would be he be willing to accept 80% of the total value if he could get it quicker? The team should arrive at the next variation on their own but allow them a couple of cycles if they need it. 

80/20 Value Game Cycle

The manager feeds in the first batch of the highest value coins. This will be about 80% of the total value. For this variation of the game the manager stops the timer when the highest value coins reach the customer.

The time will be the fastest once the first batch is the highest value of coins. If working as a SCRUM team then each team member will only have to turn over one coin. This is the fastest approach.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle. They will understand that delivering the highest value first obtains the fastest time to 80% of the features.

References

There are many references to this game or variations of this game on the internet. I haven't been able to discover it's origin to credit the creator.