Refreshing Scrum with the Ball Point Game

On a recent programme development day, Phil Ballard, one of our award-winning Scrum masters facilitated the Ball Point Game. This is an industry-known Agile game which is usually run as part of an introduction to the Agile ethos for those keen to follow the Scrum methodology. 

Despite CACI having teams that are highly experienced in Scrum, we still found this activity to be useful not only as a “going back to basics” session, but also from the several other lessons learned from our own adaptation. 

Ball Point Game: basic overview 

Teams of eight are formed, with each team collecting a bag of balls. 

Within an Iteration (of which four take place), teams pass as many balls as possible among team members, with each ball passed scoring the team a point. Teams must adhere to the acceptance criteria of each ball being touched at least once by every member, each ball returning to the same person who introduced it into the team, each ball having “airtime” as it moves between team members, lost balls being fetched and re-entering the team where it left and dropped balls not being re-introduced into the system. During each Iteration, teams will have one minute to talk among themselves and two minutes to perform the ‘Objective’. Prior to each Iteration, an estimate for the number of balls expected to pass through the team within the next Iteration is predicted. 

CACI’s spin on the Ball Point Game 

Considering teams are already experienced in delivering in scrum, we made things more lifelike by introducing additional requirements in Iterations 3 and 4: 

• The balls are being sold in packs of ten, with at least one of them being green. 
• All balls must continue to gain height as they are passed through the team. 

After all, what’s software delivery without a stakeholder wanting to change their mind? The idea behind these rules was to break the established process, force change and to see what behaviours the scrum-experienced professionals would exhibit. 

Ball Point Game goals

The Ball Point Game’s ultimate goal was to teach participants the value of continuous process improvement through basic agile principles using the simulation of an agile production process, including: 

• Teamwork/shared goals 
• Retrospectives/problem-solving 
• Planning 
• Estimating based on experience. 

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. 

Key takeaways

After all Iterations were complete, we discussed the results and asked teams to contribute their experiences with the following questions:  

• Which Iteration felt as though it was the best/worst? 
• How important was the retrospective between Iterations? 
• What changes did you make? 
• How did the team make decisions – did anybody take charge? 
• Were all ideas heard within your teams? 
• Was there anything notable in determining your estimates? 
• Were improvements made by working harder or faster? 
• Did you observe/experience anything else of interest? 

With the additional requirements added: 

• Iterative development is also based on learning from the live product and adapting to what the customer and end user needs. 
• Without anything being live, there is nothing to learn from and no way for the product to adapt. 
• Sprint teams must adapt to estimating with new requirements versus estimating on a known repeatable task. 

Additional findings from the teams

• The short timings of Iteration planning, along with the input of additional requirements, seemed to force an intensity. This, in turn, forced out several negative behaviours that we have not experienced on the programme, however, recognised within this competitive environment. 
• Low sprint commitments despite the team feeling it was a known task. 
• Sprint teams stopping when hitting commitment as there was an assumption that the game goal of the exercise was to have a stable velocity. 
• Argumentative behaviours exemplified (not the usual collaborative approach we usually see). 
• A competitive nature towards the other sprint teams, prohibiting the sharing of lessons learned. While the rules never stated they were against each other, it was inherently assumed when splitting participants into teams and asking them to perform the same task. 

On a more positive note:  

• Many questions were asked about the requirements, with a focus on what the user/customers’ needs and problems were 
• Looking outside of the team for improvement inspiration despite its interpretation as spying. 
• Reflection on what we do in practice versus the theory/Agile beliefs 
• Great discussions around the overall value of sprinting and iterative delivery. 

If you wish to find out more about the Ball Point Game or run it yourself within your programme or teams, please get in touch.