Running the Ball Flow Game

I previously wrote about the Ball Flow Game I ran at the Scrum Gathering in Amsterdam. I’ve updated the game quite a bit since then and its stabilised into something I’m finding very useful when I work with Kanban teams to help them understand some of the concepts behind Kanban Thinking. I hope this write-up enables others to use and run the game.

To recap, the Ball Flow Game is based on the Ball Point Game, with the following rules:

  • Participants play as a whole team
  • Balls must have air time between people
  • No passing to a direct neighbour
  • The start person must be the end person

The aim is to complete 20 balls (as opposed to complete as many in 2 minutes). Thanks to Rally colleague Eric Willeke I now add some fun context as well. I tell the team that they are producing magic balls. Magic is added to a ball only when everyone has touched it. If two people touch a ball at the same time, the magic is dispersed. Further, magnetic fields mean that passing a ball to a direct neighbour also stops magic being added. The start/end person is the customer wanting magic to be added to the balls. Its silly, but it adds an extra element of fun, and reinforces that the rules are constraints in the context that can’t be changed.

I use a spreadsheet to help automatically capture data about the performance of the team. (Download the template). It works using four macros, which are assigned to buttons and hot-keys:

  • Begin (Ctl-B). Begins a round by starting a timer.
  • In (Ctl-I). Captures the time a ball is added into the system.
  • Out (Ctl-O). Captures the time a ball come out of the system.
  • End (Ctl-E). Ends a round by calculating the metrics.

Once the metrics are calculated, three charts on the worksheet will populate themselves.

  • Lead Time. The time each ball took to work its way through the team (assuming balls enter and exit in the same order). The dotted line is the average.
  • Throughput. The number of balls the team completes every 10 seconds
  • Cumulative Flow Diagram. The number of balls either not started, in progress or done every 10 seconds

Upper and Lower Control Limits can also be calculated and displayed for Lead Time. They are currently commented out in the macro code because I found that they weren’t necessary for the core learning objectives. You may also need to tweak some of the macro functions for different versions of Excel (I use Windows Excel 2010). The template has worksheets for 5 rounds. For additional sheets, simply one of the existing rounds.

One of the things I’ve noticed is how the dynamics of the conversations are different from when I run the traditional Ball Point Game with teams. In particular, the team I was working with today really understood the idea of scientific management and made very small, quick and focussed changes each round as experiments, hypothesising on how the metrics would change. With the Ball Point Game I find teams want to debate in depth all the options in their attempts to get an improvement.

Note that as I said in a post of Balanced Software Development, “scientific management is still relevant for knowledge work, when the workers are the scientists.”

Here are the results. (Apparently we started with only 19 balls due to a facilitator error!)

Round 1

In this round, the customer ‘pushed’ balls into the system when he could. You can see the lead time increase as the WIP increases in the CFD, up to a point when a natural system limit is reached. Towards the end the customer stops adding more balls to let the system flush itself out a bit, which shows as the step in the CFD at about 60 seconds, the drop in lead time, and the spike in throughput. The final two balls went through when the system was virtually empty. Notice the short lead times again!

image

Round 2

In this round the team decided to limit the WIP to 6 – one per person. However, interestingly (to me at least) they decided to batch them, by getting all 6 through before they started the next 6. Lead time is much more stable this time. The spike is because the customer forgot to receive the last ball of the 1st batch before starting the 2nd batch, so it got stuck! Throughput is wildly variable though because nothing comes out for a while, and then all 6 come at once. You can see the batching in the ‘steps’ in the CFD.

image

Round 3

In this round the team wanted to experiment with an low extreme WIP limit of 1. Lead time is significantly better, but throughput is low because there is too much slack in the system now. Notice the smooth flow in the CDF. The patches where WIP drops to zero are because the customer’s process between receiving a ball out, and adding a ball in, added a noticeable delay.

image

Round 4

In this round the team increased the limit to 3, but continued to process those 3 in batches. Lead time remains the same, but with improved throughput. The CFD still shows signs of the batching with the customer delay between batches, but is much steeper due to the improved throughput.

image

Round 5

Finally, the team decided to remove the batches and solve the customer’s delay issue by re-organising themselves. This time the customer added 3 balls into the system, and then only added another when one came out. Lead time is slightly increased, probably due to the fact that there were always 3 balls in process which added some complexity. Throughput is improved again though, and the CFD is looking very smooth.

image

As you can see, the team made significant improvements over the five rounds by making small changes informed by the data they had about their flow and capability.

VN:F [1.9.22_1171]
Rating: 3.0/5 (7 votes cast)
Running the Ball Flow Game, 3.0 out of 5 based on 7 ratings

11 comments on “Running the Ball Flow Game

  1. This is a great introductory game for explaining flow and the need to change the system.

    I and my previous coaching team used this as a warm-up exercise (tracking results on a board, not electronically) at the start of our internal agile training courses. (I think we picked it up from someone at Rally originally – it may even have been you!)

    We added another extra bit of fun.
    About half-way through and early in a fresh cycle, we’d throw in a casual but encouraging comment about the sort of “best” record we’d seen for a team of this sort of size – Without saying anything about them actually meeting or beating the record.

    We made it high enough to be plausible but too high to be reachable.

    Usually the team picks up on the anchor and starts pressuring themselves to deliver more,

    Watch the number of dropped balls (“defects”) increase.

    Afterward we’d review the increase in “defects” and ask where they felt the pressure to deliver more and rush actually came from :)

    This helps give context in conversations about internal overcommitment and quality later.

    It can also encourage some “interesting” behaviour around how team members that aren’t quite as good at throwing or catching are treated in the process :)

    • Thanks for the comments. I ran this at a London Limited WIP Society meeting at Skillsmatter a few months ago – not sure if that’s where you picked it up?

      I usually add some external pressure when I run the traditional Ball Point Game. I haven’t tried that with this game yet though, but I will!

      I’m thinking about adding the ability to easily keep track of dropped balls in the spreadsheet as a way of adding a quality metric, probably charting it over 10 second periods similar to throughput. I also wonder about adding measures for ‘customer satisfaction’ and ‘employee satisfaction’ per round as these are all important areas as well.

      Karl

      I’d also like to

  2. Howdy Karl

    Nice variation; would love to give this a try at my next Kanban course.

    Just tried out the template on a mac and it gives a divide/zero error on the initialisation of the time variable. Any debug help would be appreciated

    Carlo

    • Hi Carlo,

      When you say “divide/zero error on the initialisation of the time variable”do you mean when you click “Begin” (Ctl-B) at the very start of the game? That only calls the “Start_Click” macro, which just clears cells and initialises variables.

      Maybe email me with more info, screenshots etc. If we figure it out we can post the solution here later.

      Karl

  3. Hi Karl
    Thanks for providing the template for the game, will try it out in my next training session.

    It does however seem that Application.WorksheetFunction.StDev_P in CalulateStdev() does not exist in my version of Excel (2007) and need to be replaced by Application.WorksheetFunction.StDevP (without the underscore). Not a big deal but for non technical people I guess it could be a blocker.

    Jesper

  4. Pingback: The X Penny Game | Project Entropy

  5. Karl, what do you do about balls that hit the floor? Do you allow them to be picked up (the absence of any rule may suggest this) or do they have to be returned to the start point? If they need to be returned to the start point then ultimatly you are going to get more that 20 balls flowing through your system, does this play havoc with the metric’s?

  6. Hi Mark
    I generally don’t define any policies for dropped balls so they can be picked up and don’t have to return to the start. Some teams agree their own policies. Most work out that dropped balls (i.e. low quality) have a negative impact on the system. Even when the balls don’t come out in the same order they went on, which does skew the metrics slightly, it’s not enough to hinder he overall learning.
    Karl

  7. Karl, I’ve run the Ball Game though this appears a variant in terms of capturing data. So who is capturing the data? I have the team start and stop their timers and as the game is relatively fast with innovative solutions in so far as how they accomplish the goal while living up to the constraints I can’t imagine how one gets to collect this level of data without getting in the way of flow.

    • I generally capture the data in the spreadsheet myself by looking for when balls are fed in, and come out, from the team. I’ll also ask some to play the “customer” role and feed the balls in, and receive them back. I ask them to shout “in” and “out” loudly to help out.

Leave a Reply