This describes the playbook for running the DevOps Ball Point game as shared by John Clapham on Twitter.
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.
- 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.
This playbook is targeted to a team of 14 people inside an IT organisation.
3 people play the game demonstrating how it works for everyone in the room.
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.
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.
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.
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.
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.
Remove the wall. Remind the people of the feeling of uninterrupted flow.
Play the game.