The last variation we’ll talk about is assigning value to the requirements. The Ball Game simulation is troublesome enough without giving each ball a unique ‘business value’. Numbers are written on the tennis balls, from 5-1000 points. Requirements are assigned at random (ie, nobody paid attention to the numbers when the balls were distributed), but the product owner can still maximize value delivered by trying to send the higher-valued balls through first. Obviously, dropping those high-value balls is especially hurtful.
Origin: I was working with a client that had actually developed a way of articulating business value and ROI. I decided to give them an analogue for value in the exercise to give the Product Owner something extra to consider. When they reported Velocity (number of balls), they also reported the total of all the Value points they delivered.
Reality Check: I actually like this variation a lot. The reality is that all stories are not the same size, or the same value. There is no uniformity to the work we do. There is no one way to prioritize, and no one way to execute. We do the best with what we’re handed, and we work together to deliver as best we can. And that’s really, the point of all this.
In the Ball Game simulation, proximity is key to success. The ability to catch someone’s eye before you execute a small, controlled toss. Greater distance can result in longer throws, and more opportunities for mayhem to occur. You can simulate distributed team members by placing them farther away form the core group. This simulates the additional time and energy needed to maintain lines of communication, as well as simulating the increased likelihood of errors.
Origin: I was running the ball game for a very large group in a really big room (high ceilings, and a wide enough room that we needed two projectors so everyone could see the slides of the training class. As we talked about how important co-location could be to high-functioning teams, one of the PMs in the room declared quite forcefully that they were required to use offshore team members and that wasn’t going to change. I responded with, “I’m not saying you can’t do this with offshoring. I’m saying that if you do, you need to understand the impact of having team members operating in radically different time zones and locations.” To which they retorted: “I’ve never seen any negative impact to using offshore resources. Our throughput is just as high.”
The Simulation progressed, and we were on the third round. This person’s team was pretty big, maybe fifteen people. Right as they finished their estimates for the next round, I paused the group and addressed the PM. “Is this the team that uses the offshore resources?” “Yes.” “Okay, well it has been wonderful having you visit us to get spun up on the project, but it’s time for you to return home to work from there. I need the three of you to follow me….” and I led them all the way across the room. “Here. This is India.” I walked back across the room. “This is the ocean. You can’t step into the ocean.” I pointed at both groups. “You are all still members of the same team. You all still have to touch all the balls. You still have to toss the balls. Ready? Begin.”
The PM stepped up … “No, No, No! We need time to re-estimate for the sprint.” “Why?” I asked. “I have it on good authority there is absolutely no impact to productivity by using offshore resources, so no re-estimation should be necessary. Now, please begin.”
As the simulation commenced, velocity dropped slightly, due to the increased distance for at least two of the throws. Depending on the solution the teams have chosen, they may even feel compelled to throw each ball back and fourth several times. Aim is essential. Remember, if a ball touches the ground (or the ocean), it’s dead.
Reality Check: I want to be very clear. I’m not against offshoring. I’m against cross-shoring. I don’t like when we force people from radically different time zones onto a single team and expect them to collaborate effectively. In my experience, they don’t learn to work together. They learn to work apart. It’s not good for communication, collaboration or cross-training. In order to make cross-shoring work, someone has to be inconvenienced – whether it’s someone who stays up too late at night, gets up too early in the morning, or works longer hours just to maintain overlap between multiple time-zones. It’s exhausting. And tired people make mistakes. If you want to use offshore resources, go right ahead. But instead of one team that spans time-zones, try forming complete teams in each location so the members of each team can work together, and benefit from being together. BTW, this is where having the different sized balls as from V7 really hurt in the simulation. Those lighter balls don’t fly as far or as fast – mirroring both the increased energy needed to keep the lines of communication open, and perhaps even illustrating that some work is better worked on by co-located teams.
Introduce this variant if sharing of resources is common between teams. Do this after your teams have started stabilizing their velocity so the impact is noticeable.
The first variation can be used if your organization tends to share subject matter experts. To introduce this variant, state the following at the end of an iteration. “Bob is a rare resource, so we have to share his expertise. Bob will serve on two (or more) different teams, dividing his time equally between them.”
The second variation of this theme can also be accomplished by having a single Product Owner serve two (or more) teams. The Product Owner will be running themselves ragged trying to keep balls in motion for both teams. If you really want to hammer the point home, make them do it for three teams.
A third variation can be introduced if one team is doing much better than another. Announce, “I can’t help but notice this team is doing so much better than that other one. Management is here to help. We think that the better team can help the other team to improve by sharing some of their key people. You and you will need to take part on both teams.”
For all of these variations, it is vital that you impress upon the shared people that they need to touch every ball on both teams.
Origin: How many times have you been asked to participate in more than one team/project/effort in your organization? Wearing multiple hats is a time-honored and destructive project management practice. And the reasoning is always the same, “it’s efficient”, “we have no choice”. Watch the velocities of both teams drop when you implement this change. I like doing this variant with 2 shared resources to give the teams a chance to recognize that instead of two 50/50’s, they could each get one 100%
Reality Check: The conventional wisdom is that you lose 20% of a person’s focus for every team you add them to. Thus in a 50/50 split between two teams, each person can only give 40% of their attention to each team. The remaining 20% is lost to task switching. If they are on 3 teams, 40% of their time is lost to task switching, leaving 20% for each of the teams. That’s a pretty rapid fall-off, and it’s simulated here by everyone needing to pause as the shared resources turn and re-focus on the balls that may or may not be flying at them from various points.
One of the benefits of creating agile teams is the confidence they gain through learning about each others strengths and weaknesses. A self-directed team will adopt its own way of solving problems to maximize efficiency based on what they know of each other. The longer team members stay together, the better they are.
Use this variant shortly after the teams start getting the hang of what they are doing and especially if the teams have adopted different solutions or methods. Grab two team members from one team, and swap them for two team members on another. Don’t give the teams any extra time before the next iteration starts.
Origin: One of my clients had a habit of letting their managers reassign team members at will. The rationale was that the managers knew their people best, and were moving them like pieces on a chessboard to whichever team they thought would benefit the most from that resource’s expertise. The teams never seemed to gel. Every retrospective started with a fight about how the ‘new’ team members liked their previous team’s way of doing things better. The result was less a collaborative team effort, and more of a transactional relationship. There was no reason to learn to work together as anyone could be reassigned at a moments notice.
Reality Check: Unfortunately, the practice of team member rotation is flawed from an agile perspective, as this variant will illustrate. Well-functioning teams learn how to work together. They have unique ways of facing their unique challenges. When you drop strangers into that mix, the teams have to re-form and re-normalize before they figure out how to work efficiently. Especially if their former teams did things differently. Velocity of the teams will drop, and the likelihood of errors will increase.
Reality Hurts: I lied a little. It wasn’t just one client.
Right after your teams have completed their 2nd or 3rd retro, and seem to be getting the hang of this, it’s time for this variation. Before calling them to begin, run around and swap some of their tennis balls for yellow ping-pong balls, or pickle balls, or even giant yellow pillows (pretty much anything you can do as long as it has a different size and/or weight). Then order them to begin. I guarantee you’ll get protests. You may hear cries of “Scope Creep!” At this point, simply explain “Not every backlog item a team works on is the same size or scope, and quite often after work has begun, the team realizes the work is bigger or smaller than originally estimated. This is not additional requirements! This isn’t scope creep! It represents your team learning more about the stories you’ve accepted. Please begin!”, and start the timer.
Origin: Partially because of the crumpled-paper as manager task scenario, I noticed something interesting. Similar to juggling, the players started getting accustomed to the heft and size of the tennis balls. Their repeatable pattern seemed to be dependent on the uniformity of the balls. So when they suddenly have to recalibrate to toss a lighter, smaller ball, or even a lighter one with the same size, or a bigger, heavier ball — the impact on their rhythm is immediately observable.
Figure v7.1 – Not every requirement has to be a tennis ball!
Reality Check: The truth is, this variation is more realistic than you may recognize. Teams are always finding surprises about the stories they accept into sprints. Good teams will adapt and do their best. We are illustrating this point here. In general it helps to find any kind of ball you want, as long as it’s yellow. I’ve even given them a few Nerf footballs.
For some reason, as people start this exercise, they almost always do so with a single ball in play at a time. The Product Owner tosses the first ball to the first team member, who then tosses it to the second, who tosses to the third, etc…
If the product owner thinks of their role as 1) Sending a ball to the first person in the sequence, then 2) Receiving that ball from the last person in the sequence, then the Product Owner is constrained by the cycle time of the system. As shown in Figure V6.1, the cycle time for a single ball is 6 cycles.
Therefore, if the product owner waits until a cycle completes before putting another ball in play, then they would take 18 cycles to deliver 3 balls.
After the first couple tosses, what is the PO doing? What is the first team member doing? They’re watching and waiting. Idle. Since nobody in the sequence needs to ever handle the active ball again (except the PO, who will need to take it out of play), it is fair to say that each team member is idle, far more than they are acting.
Figure V6.1 illustrates delivery cycles when the team sends out one ball at a time. Assuming the iteration is limited to 18 cycles, only three balls will be delivered in the iteration.
Figure V6.2 brings the idle moments into sharper focus…
Figure V6.2 – That’s a lot of idle time!
Think about it – each member of the exercise has only two actions, surrounded by waiting time. 1) Wait, 2) Receive a ball, 3) send the ball on, 4) Wait. What is stopping them from receiving/sending again? Nothing except the availability of another ball.
This pattern holds for everyone except for the Product Owner, who appears to 1) Send a ball, 2) Wait, 3) Receive a ball. And that’s all there is to it. Right? Maybe not.
Look at the transition between cycle 6 and 7, and also at the transition between 12 and 13. If you isolate those pairs of actions, the product owner has the exact same action structure as the rest of the team. 1) Receive the previous ball and 2) send the next ball out. Now the idle time doesn’t seem to make as much sense.
What if, instead of waiting until a ball completes the cycle to send the next ball, the PO instead sends a ball whenever their designated receiver is prepared to catch it? Team member 1 will receive a ball on cycle 1, then get rid of it on cycle 2, meaning that they could be ready for another one on cycle 3.
Figure V6.3 – Keeping everyone busy…
Now instead of 18 cycles to get 3 balls (delivered on cycle 6, 12, and 18), the new system will still take 6 cycles to produce the first ball, but new balls are delivered every other cycle after that until time expires! In the same 18 cycles, the team will have delivered 7 balls!
Figure V6.4 shows this pattern carried on until cycle 18. If we stop the simulation at this point then 7 balls are delivered. There is one troubling aspect to this scenario. Note that energy is expended on passing Balls 8 and 9 into the system when there are not enough cycles remaining to achieve delivery.
Reality Check: The perceived inefficiency of agile methods is that someone may be idle at some point in an iteration, and they’ll cite something like figure v6.2 as evidence of inefficiency. You now can counter with figure v6.3 to show that allowing the team to absorb work at their own pace produces superior throughput. And then you can show figure v6.4 to demonstrate that waste takes many forms. A team that has recognized its optimal velocity would know that they deliver 7 balls in an iteration, so the Product Owner should have prevented them from even working on the 8th and 9th ball… looking more like this:
Figure V6.5 – If the team knows their limitations, the PO would have only set aside 7 balls for them to work on.
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.
Origin: The teams came up with this one on their own, although they didn’t really toss the balls. They let gravity satisfy the ‘air time’ requirement by the receiver holding their hands a few inches below the sender’s. The sender then just dropped the balls into the waiting hands below.
Reality Check: Clever? Sure. Scaleable? Not unless you can grow extra arms.
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…
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.
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.
Crumpled paper creates a different challenge that is better served in a different variation (see V7 below). Therefore in more recent running of the ball game, I’ve started using visually distinctive tennis balls to represent these manager tasks.
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
