I can still remember the first time I played the ball point game, five years ago in Angela Druckman’s Scrum Master class. Much of the theory has evaporated but I can still recall the buzz from flow and the significance of the do – retrospect – do cycle. Feelings, it seems last longer than facts.
So when I was looking for a way to articulate concepts for the Experience DevOps workshop, I started to wonder if something based on the ball point would be useful. In fact, such a game could have relevance beyond DevOps and software development. Ultimately we’re dealing with common problems with systems and the teams that work with(in) them.
There are a number of variations on the ball point, back at Nokia Entertainment’s Bristol hub we’re indebted to Karl Scotland for his Kanban oriented Ball Flow game. Particularly for the tools to generate Cumulative Flow, Throughput and Lead Time diagrams for the game. Rapid iterations mean it’s a great way to see how those statistics change, and experiment with them in a safe environment.
When thinking about a DevOps variation there were a few things I set out to achieve, I wanted players and observers to feel the effects of interrupted an uninterrupted flow, and I wanted constraints on throughput. The process reminded me of covering a classic song, the ball point is so simple and elegant, should I mess with perfection?
If you are new to it, the classic game is described brilliantly by Declan Whelan. In summary, it is played with ball pit balls. Players aim to add magic (I prefer thinking of it as value) to as many balls as possible. Magic is added when a ball is thrown, everyone in the team must touch the ball. The ball cannot be passed between neighbors. The game is played in iterations, with a chance to retrospect between each.
Here are the modifications for DevOps:
Team Growth – the game shows how flow can be interrupted as a more people join an organization. For this we start with two or three players (you might think of them as founders of a startup), then add a couple more. At this point flow is good and the game is fun. Then, as business is booming, we add more people…
Silos – We show the disruption that can be introduced with unchecked growth. In DevOps parlance this is a physical version the infamous wall of confusion, a crude way to represent organizational, cultural or geographical separation. In the workshop, a projection screen and a couple of flip charts served us well, forcing only one touch point between teams, and limited visibility.
Incentives – As if the odds weren’t already stacked against our players we give teams on either side of the wall of confusion separate incentives, and managers.
Constrained Throughput – We add a constraint to the throughput of the system, meaning that players need to consider downstream flow. This is analogous planning and provisioning systems. It also applies in other situations, for example it’s the need to synchronize with marketing or device programs. For the game we simply use paper cups to receive balls, each has a capacity, and each has a cost: 10 seconds notice to spin up. If a cup isn’t ready the team either wait, and get a point, or drop the ball.
Start person is not the end person – The added complication of the end person placing balls in cups, and potentially requesting more, means it isn’t practical to have same person as the start and end point.
All of this sounds complicated, but it takes moments to explain and understand. Constrained throughput probably has the greatest impact on the players, successful teams will practice early involvement to ensure that that a cup (capacity) is available when they need it. If they don’t they slow down, queues emerge or the ball gets dropped…
At some point I’ll publish detailed instructions. Creating games and materials that can be shared was one of key aims myself, Matthew Skelton and James Betteley shared when we created the workshop. As a taster, the game breaks down into a number of iterations:
Iteration 1 – Founders
Two or three people play the game, this is partly a demonstration for everyone in the room.
Iteration 2 – Startup
Add a few more people, play the game
Iteration 3 – Growing Pains
Form two teams, keep founders in same team. Add wall of confusion.
Play the game
Hold separate retrospectives.
Iteration 4 – Incentives
Flow may not have improved enough – add incentives, hint at a reward. The downstream team should aim to pass as many balls as possible. Upstream should aim not to drop a single ball.
Play the game
Hold separate retrospectives. (To reinforce the point, discourage cross team communications)
Iteration 5 – Joined up incentives.
The last iteration may well have been a mess, so join up incentives for both teams.
Encourage both teams to retrospect together.
Iteration 6 – Flow
Remove the wall. Final round to remind people of the feeling of uninterrupted flow. No retro, end on a high.
We had fun with the DevOps Ball Point, and the attitude of the participants was fantastic. There was even palpable relief when the wall of confusion was broken down; if only it were so easy in a real organisation!
Erratic Mumblings 
John, I’m interested in hearing your view of how the modifications work as opposed to the simply version? i.e. do they continue to add value and give more learning or does it make it too complicated.
I think the constraints add value, particularly bringing an appreciation that downstream flow can be effected by upstream bottle necks. After an initial phase of only caring about team output the players soon start to consider the whole system. There is a cost of course, the game takes longer to get started, because more explanation is needed, and there are extra rules to track,