Agile games – ball point game

I recently had the privilege of working independently with one of London’s top media companies and helping them to rejuvenate their agile roots.

I ran an all-day workshop as a refresher on agile principles and practices and as a warm-up exercise I played this game.

I was really happy with the results. The group seemed to have such a lot of fun doing it, which got everyone into a relaxed and participative frame of mind, and there were so many interesting parallels with agile and lean that it provided a really useful basis for reflection and discussion.

I played the game with about 50 people in a large meeting space. The room was large but it wasn’t enormous, and it worked well despite the large size of the group.

To play the game, you will need a lot of balls, if you’ll forgive he expression! I found that tennis balls worked well and I had 60 balls for a group of 50 people. You will also need a stopwatch, and a flipchart and pen.

Here is how it works…

The object of the game is to pass as many balls as possible through the team in 2 minutes. There are relatively few rules, but they must be adhered to. These are effectively the team’s constraints. Here they are:

• if you’ve played this game before, please participate silently so you don’t spoil it for others.
• if you’ve played this game before, please participate silently so you don’t spoil it for others.
• every team member must touch each ball for it to count.
• as each ball is passed between team members, it must have air time, i.e. It must not be passed directly from hand to hand.
• you cannot pass the ball to the person immediately to your left or right.
• if you drop a ball, you cannot pick it up.
• there will be a penalty (points deducted) if you break any of the rules.
• every ball must end where it started. For each ball that does, the team scores 1 point.

You have 2 minutes to self-organize and plan your approach. One person from the group will write on the flipchart an estimate of how many balls the team thinks it can do.

You will then play the game for 2 minutes. At the end of the game, you will record on the flipchart how many balls the team actually managed to do, alongside their original estimate.

You will then spend 1 minute learning how to improve, making a note of what the team has decided to change on the flipchart next to the estimate and actual. Then do it again.

In all, you will do 5 iterations, recording the estimate, actual and changes each time.

It was really fascinating to watch how the team self-organized, how they communicated, and to observe where the leadership came from and in what style. It was also really interesting to see how the team learned, and how their estimates became more accurate until they changed the process.

The lesson here is that all processes have a natural velocity. To speed things up, it is often not a case of working harder or faster, but a case of changing the process.

Some of the other parallels with agile or lean, and some of the questions worth posing to the team, are:

• what happened? which iteration felt best? why?
• were improvements achieved by working harder or faster?
• processes have a natural/optimal velocity
• were there bottlenecks? how were they identified?
• how well did the team self-organise?
• were interjections of experience (from person running the game) useful? if so, even self-organising teams should take guidance from people with relevant experience
• the game had a natural rythm and flow, like continuous flow advocated in lean thinking
• people were not disturbed during the process
• ‘pull system’ maximises flow – no point throwing balls to someone who isn’t ready to catch them
• the team had a shared goal and was focused on a common purpose
• face to face communication – would it have worked as well if communication was by phone or by email?
• would it have helped to document the process?
• power of the retrospective – concept of ‘fail fast’ and learning quickly as a team
• shows the idea of sprints or iterations, where the team goes through repeated cycles of plan, do, review, …
• where did the leadership come from? and in what style?
• using the number of points as a simple measure of the team’s results, did the estimate and actual start to converge? (until the process was changed)

During the game, you may need to give some hints to help the team learn in such short, limited timeframes. Try not to make the hints too obvious too early in the game. For instance, after a couple of iterations, during the learning minute, you might want to give the team clues, such as eliminate waste, maximize resources. Later you might want to hint that they should use both hands, and later still that they could cup heir hands together to drop fewer balls (less waste).

I played this game for a second time and it was also interesting to see that both times in the first iteration, the teams neglected to put any system in place to count their score and measure their output. As a result, they had no idea how well they’d done and if they didn’t put this right, they would have no way of telling whether their changes were really effective. I thought that was a great way of demonstrating the value of velocity.

All in all, it was a great ice-breaker, was good fun and was very thought-provoking. Later in the day, people regularly referred back to concepts demonstrated by the game.