It was at the Spring Scrum Gathering 2008 Chicago that Tobias Mayer did an Open Space session on simulations to help get Agile ideas across to people, in a way that brings them to life. One that was new for me at the time was the ball game, originally blogged about by Boris Gloger.
I have been using this simulation regularly on my Agile training courses, as I get more familiar with the game I have started to get better results in terms of the learning’s coming out. Yesterday I had the best results yet, which is why I wanted to write this blog. I am not going to give away what the team did, but I do want to talk about what and how they learned.
The basic rules are – the whole group is one big team, the balls (tennis balls or those soft squidgy balls are good, probably not cricket balls) are taken from a container and passed amongst the whole team back into the same container (a bin often works well), this equals one point, however:
The balls must have air time
Balls that hit the floor don’t count, and have to be returned to the starting point to get them back in play
No balls to your direct neighbour
Start point = End point (i.e. the container)
Iteration = 2 minutes
In between = 1 minute, to review and plan
Play 5 iterations
To set the game up you explain the rules, let them plan for a minute and then ask for an estimate of how many balls they will score in the iteration. The planning and estimating then happens before each iteration.
The number of balls that a team successfully return to the container will very much depend on the number of people you have, the number of balls you have and how long you make your iterations. Yesterday while co-training with Matt Roadnight we did this with a team that managed a 600%+ productivity increase by the end of the exercise; it was a team of 10 with 8 balls doing two minute iterations, results below:
The wonderful thing about this game is that the learning’s are always valuable but depending how the game goes different things stand out.
In the first iteration the team started out with a good strategy and was reasonably pleased that they smashed their estimate. I was a little worried because I thought they might struggle to find much improvement. In the second iteration they made a small adjustment which allowed them to improve, by the end of the third iteration their estimate was very good compared to their actual.
Learning 1 – Teams become predictable
The team had got into a rhythm of delivering balls through the system; their performance had reached a plateau, which is great because the team become predictable, as they get better at estimating based on their history of delivering.
I thought that maybe the team was as productive as it could be, I decided to push them a bit, as Product Owner I said I wanted more, I had seen other teams do a lot better than this after 3 iterations, I wanted 75 balls. Now I do this to see if they will take the bait, without major change to how they were working there was no way they could have done what I asked for. They did take the bait, but they also came up with a major improvement which allowed them to smash even my challenge.
Learning 2 – Removing impediments can lead to significant improvements
By the end of iteration 3 some people may have assumed that the team was hyper productive, but actually they had probably just reached an organisation impediment that was stopping them becoming more productive. Within their environment they had made a number of small changes that led to the plateau in performance, they had reached an organisational ceiling. However in the planning for iteration 4 the team challenged two assumptions they had about the game, and thus removed some constraints, very similar to changing a process that was constraining them.
Learning 3 – The power of Inspect and Adapt
This is the most important thing that comes out of the simulation. In the debrief I always ask the team what do they think would have happened if I would have got you to spend 15 minutes to do as many balls as you could, rather than having two minute iterations with a 1 minute opportunity to reflect and plan. The obvious conclusion that the team came to was that they would have at best carried on at a rate of 24 balls every couple of minutes, but would have probably slowed down, or even resigned due to boredom before the 15 minutes was up. They certainly wouldn’t have identified those major improvements that allowed them to exceed my challenge in iteration 4. Taking time out to Inspect and Adapt is investment time, but if it can improve the teams performance by 600% after 5 iterations it pays for itself.
Leaning 4 – Agile can be fun and it helps build a sense of team
The iteration gives the team a short sharp focus to try and achieve something together; they get this regular reward as a team of having achieved something. Participants also got more collaborative and the ideas started flowing the more success they had.
Learning 5 – Knowing where you are in the Sprint helps the team focus on achieving the goal
This was an unexpected learning. In the 3rd and 5th iteration Matt called out the timings every 30 seconds or so. We expected them to start rushing to achieve their goal, and start to drop balls. What actually happened was that because they had a realistic goal, the team visibly concentrated more on what they were doing. This is like the team glancing over at their Sprint burndown, identifying that things were going ok, but focusing that little bit more just to make sure no balls were dropped.
Other learning’s
Other learning’s I have had out of this game in the past include:
· In order to maximize flow it helps to limit work in progress.
· If the team tries to speed up to achieve a goal (i.e. I say give me 75 and they don’t make any improvements), they will drop more balls, this is like introducing bugs by trying to get through more features.