For those of you that believe in learning through play, the ball point game (invented I believe by Boris Gloger) is one game I can heartily recommend.
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:
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:
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.