How to Change a Workshop In-Person Game to a Remote Simulation for Effective Results

If you took an agile workshop sometime in the past 15 years, you probably played the “ball game.” That's where people emulate a Scrum approach, complete with asking the team to do “more.” As described in the link above, it can be a terrific simulation.

There are many reasons to use simulations when trying to teach people new material. Simulations make it easier to learn from “failure.” All change requires learning, and that learning often creates chaos where people's performance is uneven. See the Satir Change Model description in Where Are You in Your Changes?

However, the ball game requires everyone to be in the same room to play. Worse, too many people aren't excited about the game. They say, “I don't do anything similar to passing balls. Why do I have to play a game?”

They have a point. Especially since they've probably suffered through way too many “agile” workshops with more and more games. And very few organizations want to take the time to bring people to one location where everyone can be in the same physical place.

We know simulations can help people practice safely. Plus, we know that people want to see the applicability of a given simulation to their jobs. And we need to make that simulation something that works when the team is distributed.

(Note: I am not addressing a workshop with some people “in person” and some people distributed. I don't teach those workshops because they layer way too many collaboration problems on top of the actual content.)

That's why we can use principles to create distributed simulations from in-person games or simulations.

Assess the Principles Behind the In-Person Game or Simulation

The ball game  uses several principles:

• Limit WIP using a timebox.
• The team must keep the balls in the air. A dropped ball is a defect.
• Periodically, the team retrospects and replans.
• The team organizes itself.
• Show how an interruption increases WIP and creates an even more  intense focus on individuals, not the team.

There are several “rules” that show how we've changed since the game started. One of them is that you can't pass the ball to the person to the left or right of you. (That's an example of how insidious resource efficiency thinking is. When I created my agile simulations, I asked people to collaborate on the work with pairing, swarming, and mobbing.)

Now, use the principles to create a new remote simulation.

How to Create a New Remote Simulation That Showcases Agile Principles

Here's just one alternative that scales for almost any team size.

1. Create the simulation environment for the team: Decide on a universally accessible whiteboard or common document. (I don't care what it is, as long as everyone has equal and easy access to that board/document.)
2. Ask the team to choose one of their current team-based problems. I like to ask them to choose a challenging production support problem, or something else that's making them nuts. Something they want to address now.
3. I explain the activity in this way: Your managers wanted you to fix this problem yesterday. You're not going to estimate anything, because if you knew how long it would take, you would have done it already. However, I expect you to:
   1. Collaborate to solve the problem.
   2. Show a demo of whatever you complete at the 15-minute mark.
   3. Retrospect and replan at that time.
4. I do not ask them to do anything else. Since too many teams do not know how to collaborate on problem solving, I explain the difference between brainstorming out loud and brainwriting on some form of “paper.” Brainwriting helps everyone contribute in ways that just discussion does not.

We now have a team environment that can use agile principles, but we're not quite done.

Organize the Rest of the Simulation

For the most effective simulation, I use volunteer observers from the team:

• Fewer than 8 people: one observer
• 8-15 people: two observers
• 16 or more people: three observers (and they had a devil of a time keeping up. I might do more observers now.)

The timing: I use a 15-minute timebox, followed by not more than 5 minutes of a demo. No extra planning time. That's because I want people to have a bias for experiments and learning from them, not a bias to a lot of planning.

I then start the timer. The observer(s) notes how the team works: How does the team manage their work? How do they collaborate? Do they choose to do “real” planning, whatever that is? When does the work go back and forth in state?

If the team tells me they get interrupted all the time, I let them run one 15-minute “iteration” and then either someone else or I will pull a person away. The observer(s) check for what the interruption does for the team when the person gets pulled and when the person returns.

I tend to run the simulation at least three times, for a total of 45 minutes plus up to 15 minutes of demo time. If the team thinks they are close to finishing their work, I might offer another 15-minute timebox. But not more, because they don't know when they will finish. We have enough information now—it's time to debrief.

Debrief the Simulation

My go-to remote debrief is an ORID debrief. (See a quick explanation at Using Behavior-Description Questions as a Starting Point. Let me know if you'd like a post about ORID in the future.)

Since the people worked on the problem, I ask the observers to show their data. Not interpret, but it's a “just the facts” approach to seeing what the team did.

Then, as I ask more questions, I remind people to write down their answer to each question. Depending on the team, I ask people to work alone, in pairs or triads, etc. It depends on the team itself, both the size and the people.

The debrief makes it possible for people to learn.

Effective Results Arise From a Thorough Debrief

Too often, I see facilitators rush through a debrief. But that might confuse people and make it even more difficult for everyone to see the applicability of the simulation to their work. That's one of the reasons I tend to use the team's work and not a fake game. I feel as if the team's time is precious, especially if they are distributed/remote.

In From Chaos to Successful Distributed Agile Teams, Mark Kilby explained his Compass Exercise for how he starts converting activities. You can see a version of that here: Converting Exercises for Online Facilitation – the Jumpstart Storytelling Exercise.

Okay, what did I miss?? Ask away in the comments.