Sometime after the start of the second or third iteration, spring this
little trick on the team that is doing the best. While the balls are in motion,
wander into the middle of their communication pathway and say something like,
“Hey! Are you guys doing Scrum? I’ve heard about this! Is this one of those
stand-up meetings?”
Origin: Just before calling for the iteration to begin, Jack arranged to
have someone call his cell phone. The team was entirely focused on using their
newest throwing pattern to improve their performance, when the phone started ringing,
and Jack, phone pressed against his ear, absent-mindedly wandered right into
the middle of the circle, having a ‘conversation’ about how wonderful the
session was going. The members of the team were trying to figure out how to
keep the balls in motion with this obvious obstacle standing in line of sight
to their ball recipient. And to make matters worse, he was a moving target,
turning, walking and talking in the middle of the circle while the team tried
to do their work. It was brilliant!
Reality Check: How many times has a well-wisher wandered into the middle
of your Daily Scrum? Get used to it. If you are an early adopter of agile, as
news of your experiment in agility spreads, so will the curiosity about how you
are doing it. It could be as simple as that, or as complicated as someone
breaching protocol and calling team members directly, breaking their flow. It’s
an illustration of an all-too-real situation.
This gives you a chance to reinforce with the team that they should only
accept work from the Product Owner
The Ball Game simulation does a great job of teaching some basic agile principles. In all honesty, if you stopped reading right now, you’d be good. The lessons taught by the native form of the Ball Game are powerful, and quite robust. There are certainly more things the team can learn, but the items enumerated in the previous section are the high points.
Variations on the Theme
When running a simulation, it is incumbent on the facilitator to do whatever they can to ensure that the participants have a good time, and learn from the experience. I had the good fortune to be present while a mentor of mine sought to enhance the experience for the team running through the simulation. The first two variations below were initiated by a mentor of mine named Jack Walser who managed to amp up the fun, and light a spark of possibility in my head.
Once that door was opened, I started seeing opportunities to further tweak the game and expand the lesson footprint. And that’s where this section will guide you.
There are a lot of variations that you can insert into this game. The following variants came as direct or indirect inspirations through the context of specific training sessions. I’ve tried to include the context that inspired each variation. The learning potential here is off the charts.
So what do you think? Could these variations help you and your teams in your Agile journey? Can you think of other scenarios and variations? I’d love to hear from you.
The Ball Game is a simulation I like to build into my Agile training curriculum. After a series of iterations and self-discovery, the players will recognize certain truths that turn out to be key to successful agile practices. Some of these lessons are detailed in this part.
Core Lessons
Let’s take a moment and explore the core lessons in detail.
C1 – Planning is Important
This is a core lesson of the Ball Game. Unless the team comes up with some agreed-upon way of passing requirements among themselves, things quickly devolve into chaos. Balls get dropped. Steps get skipped. The first iteration of the game is pretty chaotic.
Reality Check: Agile works better if you sit down and plan out how your team will interact. The need for a working agreement is intuitively obvious. You’ve never done this before, in this way, with these people. So why would you think everyone will just ‘know’ how to interact?
C2 – Time Boxes Cause Stress
A player in this simulation is usually in for a shock when the facilitator declares that ‘planning time’ is over, and it’s time to run the first simulation. I guarantee someone is going to complain or ask for more time. Don’t let them. Encourage everyone to do their best and assure them they will get a chance to improve in the next iteration.
Duration of Planning is a factor here. In the simulation we deliberately time-box planning to force the team to make a plan quickly. This is partially to simulate that you don’t have an infinite amount of time to derive the “best” solution all the time. Sometimes you only get enough time for one idea. More time does not necessarily equate to better solutions. Sometimes the best confirmation that your method is sound will be found when actually trying it out.
Reality Check: I know there are people in the group who would plan this thing to death, orchestrating each toss down to the microsecond. They would do so with the best of intentions. They would do so in the name of efficiency and throughput. But ultimately, they would waste everyone’s time. Because you can’t plan for every contingency. We put the team in the time box to force them to feel the stress of having to follow a schedule. We also do so to illustrate the point that even the most perfect plan won’t account for everything. Often in agile circles the team must take a leap of faith and begin moving without having all the facts. We want them to experience this. And finally, it starts to introduce the notion that we’ll learn more by trying, failing, and adjusting that we would by just planning alone.
C3 – Skill Plays a Part
Another core lesson of the Ball Game. Your plan may be perfect, but execution is still a factor. It doesn’t matter if you know you need to throw each ball to Joan, you also have to be able to get the ball to Joan. Some people just have terrible aim.
Reality Check: In the Real World, not everyone on your team is immediately skillful at collaboration. The act of tossing a ball from one person to another simulates this fact. When you first start doing agile, you’re not going to be perfect. Accept this. Practice to get better.
C4 – Faster is Not Necessarily Better
This Core Lesson usually sinks in around the second iteration. In order to improve, the team just tries to throw the balls faster. When they go faster, their aim gets worse, and people’s reaction times become a factor.
Reality Check: This simulates the fact that wishing to go faster doesn’t mean you will. The team can only go as fast as their skill allows. If they try to go faster, defects slip into the system and balls get dropped.
C5 – The Importance of Communication
You’ll see it right away. A ball will be thrown, the intended recipient will turn to face the thrower, and it bounces off their chest, head, outstretched hands…it doesn’t matter. It’s now a dead ball. A defect. Maybe it was the heat of the moment. Maybe it was that the team agreed that we could put more than one ball in the air at a time. Those are both great ideas. With great power comes great responsibility.
Reality Check: There are a lot of balls flying around. Don’t forget to let Joan know when there’s a ball flying at her face! Seriously! Throwing things over a wall and hoping the person at the other end is ready for it is just asking for trouble.
C6 – The Importance of Retrospectives
Perhaps the most important lesson to learn here, is that you can’t improve the system without talking about how to improve the system. Those retrospective sessions, brief as they are, provide a tremendous amount of value in improving team performance.
Reality Check: The Team needs to talk through the way they work and try out new ideas. Whether they revamp their entire strategy, or simply move a little closer together to shorten air time, these sessions are as vital to the simulation as Retrospectives will be to their Inspect & Adapt cycle in Agile.
The Ball Game is a simulation I like to build into my Agile training curriculum. The rules of the game are quite simple and were introduced in the “Intro” post. What follows is is discussion of some common solutions I’ve seen teams come up with for the core rules.
Solutions
Two common solutions for a six-person group are illustrated below.
The first is a simple star pattern (or circle), where the initial intent was to have each person throw the ball to the next person beyond the person to their immediate right or left. Each ball effectively circles the group twice. If there are an odd number of people on the team, it works perfectly getting back to the product owner. If there is an even number of team members, then a little creativity is required to get the last ball back to the Product Owner without violating rule 6. This variant is a lot of fun to watch, especially if they get more than one ball moving at a time.
Solution 1 – Star Pattern – six people
It seems rule 6 (no tossing to the immediate right or left) is the most troublesome. Solution 2 is an interesting variant because it involves the participants facing off in two lines, and tossing the ball across from one line to the next, instead of next to them. In the end, the last player has to throw the ball all the way down the length of the line, back to the product owner – which could result in a dropped ball. I did see one group that had so many people, they were able to loop the two lines around so the line ended right next to the product owner.
Solution 2 – Face to face
There are other variants that are harder to illustrate. One involved the team members cupping their hands, one above another forming a virtual tube for the balls to descend through. The product owner dropped a ball in the top, then crouched down and cupped their hands at the bottom to receive the ball after they fell through the last set up hands. The solution does not violate any of the rules, and it makes dropping a ball very unlikely. But the product owner ends up standing and squatting down in rapid succession throughout the iteration. If they’re not in good shape they could wind up passing out! 🙁
Okay. So we’ve looked at the rules of the game. We’ve seen a few sample solutions. What have we learned from all this? The Core Lessons are discussed in Part 2.
There is a simulation I build into my Agile training curriculum. It is based on a very old game that has been used for ages. I’m not the inventor of the game, but I am a very strong adapter of it. Here I examine the core game followed by variations I have used…
