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:

  • if you’ve played this game before, please participate silently so you don’t spoil it for others.
  • you are one big team – you cannot change your team size.
  • 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.


Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
41 Corsham Street
N1 6DR
United Kingdom


101 Ways Limited
No.1 Spinningfields
Quay Street
M3 3JE
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at