Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Playbook of the DevOps Ball Point game

DevOps Ball Point game

This describes the playbook for running the DevOps Ball Point game as shared by John Clapham on Twitter.

The Objective

Pass as many balls as possible through the team into the paper cups.


  • something to create a wall: 2 flipcharts, a whiteboard, a projection screen or office space dividers
  • 120 balls seems to be the right amount
  • 60 paper cups that each can contain 2 balls
  • a flipchart or whiteboard to record the number of balls passed through the team.

The Rules

  • Each ball must have air-time
  • Each ball must be touched at least once by every team member
  • No passing of the ball to your direct neighbour.
  • Start person is NOT the end person (as opposed to the classic Ball Point game).
  • End point is a paper cup, which has capacity and cost (10 seconds to spin up). If the a cup is not ready, the team can either wait for a cup to get ready and thus gets a point, or it drops the ball.
  • Two minutes per iteration.
  • One minute for continuous improvement.

The Playbook

This playbook is targeted to a team of 14 people inside an IT organisation.

Iteration 1 - Founders

3 people play the game demonstrating how it works for everyone in the room.

Iteration 2 - Startup

Grow the team to 6 people and play the game.

question: should we hold a retrospective after iteration 1 and 2 ?

Typically no, these iterations are just about establishing the story and showing people how to play the game.

Iteration 3 - Growing Pains

Form 2 teams of 7 people each keeping the founders in the same team:

  • an upstream team, consider it as Development
  • a downstream team, consider it as Operations Whenever a paper cup is full, Operations needs to bring in a new paper cup.

Add the Wall of Confusion: teams can only pass the ball to each other through one touch point.

Wall of Confusion

question: should we use a paper cup as touch point ?

That's an interesting idea - making it harder to cross the wall would reinforce the damage of the bottle neck. My guess is that this would confuse people because cups would have two purposes (servers at the end of the line, and at the wall), practically it might also be too hard - the wall shouldn't make play stop all together.

Play the game.

Hold separate retrospectives. Teams are discouraged to have cross team communications.

Iteration 4 - Incentives

Development aims to pass as many balls as possible. Operations aims not to drop a single ball.

Play the game.

Hold separate retrospectives. Again teams are discouraged to have cross team communications.

question: at this point shouldn't the teams have a joined retrospective to prepare for the following iteration ?

The aim is is to get the teams realise how damaging the wrong incentives are by encouraging them to optimise for the team's goals rather than the organisation. As such I'd recommend they retro separately, the act of either a)thinking up even more destructive habits or b)releasing they need to join up, should reinforce learning.

Iteration 5 - Joined up incentives

Incentives are now joined for both teams: pass as many balls as possible without dropping a single ball.

Play the game.

Hold a joined retrospective.

Iteration 6 - Flow

Remove the wall. Remind the people of the feeling of uninterrupted flow.

Play the game.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment