There is a simulation I like to 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.
The Ball Game
The game starts, as most do, with everyone in the room forming up into loose groups of teams to learn the rules:
- You are a Cross-Functional Team
- Each Ball Represents a Requirement
- All Requirements are put into play by the Product Owner.
- All Requirements are removed from play by the Product Owner.
- Each Requirement must be touched at least once by every member of the Team.
- When Passing a Requirement, it cannot be passed to the person to your Right or Left.
- When Passing a Requirement, it must have Air Time (no two people may touch the same ball at the same time)
- When Passing a Requirement, if it is Dropped, you cannot pick it up.
- Planning – The Team estimates how many Requirements they can “deliver” in 1 minute, they record this value in the “Estimate” column.
- Execution- The Team executes their plan for 1 minute
- Review – The Team records the actual number of Requirements that satisfied the acceptance criteria. They also record how many ‘dropped balls’ (defects) there were during the round.
- Retrospective – The Team takes a minute to discuss how to improve their process.
These rules are quite common, and there in really no difference here between what my teams start with, and what all the other ball gamers do. In fact, if you were to run the simulation for a couple of teams, for a couple of “sprints”, then within a half hour, they would have probably run four or five iterations and improved their process dramatically.
Upon completion of the simulation, following only these rules, the teams would learn some valuable agile lessons like:
- Planning is important
- Time Boxes Cause Stress
- Skill Plays a Part
- Faster Isn’t Necessarily Better
- The Importance of Communication
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 obviousyou’ve never done this before, in this way, with these people. So why would you think everyone will just ‘know’ how to interact?
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.
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.
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.
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.
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.
Variations on the Theme
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.
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, which 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 rest of these came as direct or indirect inspirations from the context of the training session. I’ve tried to include that context that inspired each variation. The learning potential here is off the charts.
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
Sometime after the start of the second or third iteration, have someone walk up behind a member of the team with a visually distinctive Requirement, and ask them to “get this done too”. It helps if this person is in the middle of the workflow (not at the beginning). Some folks will grab the new ‘ball’ and just toss it to their normal partner. Some will recognize that this is unauthorized work and ignore your request.
Origin: This is Jack’s second variant. On that day, we used a crumpled-up piece of paper to represent the goldilocks task. With almost no drama, the team member snatched the crumpled paper, and tossed it to his partner, who in turn passed it on to their partner. The paper got to the product owner, who simply shrugged and set it in the ‘Done’ pile with the other requirements. The genius of the ploy became apparent at the retrospective when the team tried to claim credit for the task. Jack asked them if every member of the team had touched the Requirement (remember, he gave it to someone in the middle of the pattern). When the team said that it had not, Jack declared the requirement ‘incomplete’, as it had failed to meet the definition of done.
Reality Check: At first the team might get angry about losing the credit for the requirement. But it really serves to illustrate two points. 1. Only your Product Owner should be giving work to the Team, 2. Incomplete work is incomplete work. It took time from the team’s capacity, impacting performance
The Importance of Training
I usually like starting the Ball Game exercise right after a break in the training class when I’ve declared that we’ll start again at a specific time. This almost always ensures that if I keep my word about start time, that somebody has failed to come back to the classroom on time. I deliberately don’t recap any of the rules that have been explained. These team members have essentially missed out on the training (rules). It works even better if the round has begun and you just assign them to join a ‘sprint’ already in progress. They generally fall prey to some of the esoteric rules of the game – usually the airtime, right-left, or the dropped-ball rule. Suddenly the team will start shouting orders at the new team member, trying to explain the rules while mid-volley. It’s wonderfully chaotic.
Origin: This is the first of my personal variants, and it happened organically. The team was already tossing balls around when two of their teammates wandered into the classroom. They tried to sit down, and I made a point of calling them up to participate with one of the teams, making sure they were right next to each other. One of them received a tossed ball, and naturally handed it to their partner in tardiness, breaking the right-left rule AND the airtime rule in one fell swoop. I swept in and plucked the ball out of their hands. “Rules violation. Dead ball”. As they were processing that a tossed ball went wide. “Rules violation. Dead ball.”
Reality Check: I can’t tell you how many times I’ve seen organizations make the commitment to training the first group of agile transformation teams, then decide this is unnecessary for subsequent team members. They toss relative newbies into a team and expect the rest of the team to educate them on the fly. The metaphor here is both obvious and effective. Note: if you think this is an important lesson for your group to learn, snatch a couple of volunteers to stand in the hallway until the exercise is in full swing. Sometimes we make our own luck.
Team Size is Important
There’s a reason why agile methods emphasize smaller teams: the overhead associated with many lines of communication is a drag on productivity. You want proof? Take a large team that has figured out how to deliver, and then split it into two teams, each with their own product owner. Within a very short period of time you’ll see the two teams are going to outperform the single large team.
Origin: The first time I saw this, it happened organically. I had explained to the class that they needed to form into teams, and each team needed a product owner. That particular class only had one person who was designated to be a product owner, so she assumed that role, and the other twenty-five people just sort of gathered around her. As you can imagine, it took a very long time for a single ball to pass through all the various team members’ hands, so :
- Their velocity of completed stories was quite low
- There was always a ball in play (unfinished work) when the time expired
- There were statistically many more opportunities for the team to flub a toss (drop a line of communication)
- For the vast majority of the round, each individual team member was idle, waiting for the current ball to complete the pattern before the next ball started, and they finally got a chance to catch and toss the next requirement.
“You would think”, I commented wryly, “that with this much horsepower on your team, that you’d be able to get a lot more work done.”
“But you said we had to have a product owner on each team, and there’s only one product owner here.”
“I never said the roles in the simulation needed to mirror reality, so technically ANY of you could play the role of Product Owner.”
With that perceived restriction removed, they split into three groups, and almost quadrupled the overall number of balls they got through the system each round.
Reality Check: In this variation, there’s a very simple explanation for the increase in productivity, namely each ball needs to only be handled by half as many people, and thus will traverse a shorter distance. But don’t let that discourage you! In this simulation, the passing of the ball represents the maintaining of lines of communication. There was another way they could have handled it…
Sticking with the big team scenario above, what if instead of splitting the teams, they decided to toss two balls at a time (one in each hand)? I’ve seen it done. It’s a great way of simulating that doing more than one thing at a time leads to quality issues. The number of dropped balls tends to go up, and the number of balls through the system does not tend to double as each toss takes slightly more ‘care’. to execute.