Ball point game - debriefing and options

The ball point game is a fun exercise to help people understand a whole bunch of ideas for agile/lean/scrum. I have been running the game regularly over the last six months and thought I would put together some variations I play with.

The game was invented by Boris Gloger but I picked it up from Rowan Bunning and you can read the instruction on Kane Mar's blog.

Most recently I have been running the ball point game after a discussion on continuous improvement as the game lends itself beautifully to this. After running the game as described in the links I like to ask the following questions:

1. Who had all the ideas?
2. What roles did you all take?
3. When something went wrong what did you do?

I haven't found a team yet that doesn't give answers like:

1. No one had all the ideas, we all suggested ideas and tried some out.
2. Apart from the person starting the cycle there were no roles.
3. We tried to work out how to fix what went wrong.

I then ask the team to compare this way of working with their usual delivery process, thinking about the three questions again.

Then ask about flow, improvement, reinforce the PDCA cycle ideas.

Dysfunctional forms

Odd balls

For running the ball point game I like to have a mix of balls. Various sizes, textures and weights. The variability greatly interrupts the flow of the team and several teams work out that as the balls all have the same value (one point) they might as well discard all but one type.

Debrief - the varying ball sizes are like varying sizes of requirements (stories, PBIs etc). With varying sizes it's difficult to create flow. As requirements are information there will be some variation but there needs to be effort put it to even these out to allow teams to develop flow.

Multi-tasking

As the team is going so well (after the 5th iteration) I need to take some people out of the team to help another team to do better, so these guys will be available part time. All rules stay the same and the part timers are considered part of the team.

To make this happen the part timers need to stand with their hands behind their backs when I say so - this is when they are working with another team. The team has 2 minutes to plan and give an estimate.

When running the iteration I watch the clock and call "out" to signal the part timers are to have their hands behind their backs and "in" for them to return to the team. The whole team stops when I call "out" and restarts when I call "in".

This is not a fantastic analogy for multi-tasking, it would be better to actually have two teams going at once and have these people on both, or have the people walk away from the team to give them as sense of task switching maybe I'll try that some time.

One team recently put the part time staff at the end of cycle, and when they were "out" the team put all the balls in a bucket ready for these guys when they started again. What happened was the bucket near the end filled up quickly, never emptied and the original ball source ran out of balls. This was interesting to debrief to help these guys see the problems of a push workflow with the throughput constraint on the end not having any control on what was coming in - dunno if I succeeded with that.

Debrief - multi tasking can really interrupt flow. People working on multiple tasks/projects/teams make it difficult to get work done.

Problem - this makes it look like people working part time are a pain in the butt for delivery.

Co-location

Another fun dysfunctional form is to stop the team from co-locating. Give the team the usual planning time but no team member may stand within 3 metres of another. All the rules are the same.

Debrief - it's harder when you are not right next to someone you are working with. It's more difficult to respond to what they are doing and vice versa. There is essential non-verbal communication that you can have when you are co-located that helps to enable more useful verbal communication.