Games with Distributed Teams at Play4Agile 2013: An unexpected takeaway

One of the most vivid sessions I took part in at the Play4Agile conference in Germany last month was a session on Games for Distributed Teams.  Led by the amazing Silvana Wasitova, this discussion built on the preceding session about “Games in 5 Minutes” to explore how these activities can be used with distributed teams.  I was hoping to get some new ideas for games to use with teams that are not colocated, since in my experience it’s rarer and rarer to find teams where everyone is located in the same city, let alone the same office. While we talked about and tried some games that could be played across a group of people connected only by a phone line*, for me the fascinating part was how this experience could also be used to demonstrate why there is really no good substitute for in-the-same-room face-time for teams that need to work together.

My discomfort started with the distributed seating arrangement in the room.  Rather than arranging chairs in the usual informal circle, Silvana lined up participants along either side of the room with a row of tables in the middle.  This immediately created an unsettling sense of disconnection with half of the group, though we were sitting only metres apart and could see each other clearly.

We then played a very simple name game, where each player says their name, followed by a word starting with the first letter of their name, and then the next player tags their name and word onto the name chain alternating from one side of the room to the other: “Ellen Eggplant, Sven Serendipity, Henna Hornet….”. This was easy enough when players were seated facing each other.  But then we replayed the game with one row of players with their backs turned to the room, and a row of dividers down the middle to block the sightline from the other side.


The difference in the two experiences was astonishingly visceral.  Firstly, the game suddenly became much harder, even though we had already had a practice round which helped with learning everyone’s names and the flow of the game.  Without being able to see the other players, remembering the order of names and the second words was somehow much more difficult and the repetition of names proceeded much more slowly.  The other thing that really hit home was how easy it was to disconnect from the activity once we weren’t actually looking at each other.  I stood up with my iPad to take the picture of the room and because I’d already had my turn, once the picture was done it was too easy to tune out for a moment to check Twitter and email rather than attend to the game – even though we were all still in the same room, mid-session, engaging in a very brief activity.  Embarrassing, but illuminating and all-too-familiar**.  In the debrief afterwards, other people related experiencing a similar sense of disconnection once people in the game were no longer looking at each other throughout.

We then talked about some other ideas for games for non-colocated teams, such as the excellent on-line Innovation Games that I have used successfully for retrospectives and brainstorming when participants can’t all be in the same room.  But despite all the great ideas, what I really learned from this session is how to create a simple exercise to really show team members (and their leaders) what the effects of sitting apart – even without leaving the same room – can be on intra-team communications.


*<rant> maybe it’s an Ottawa public-sector peculiarity, but many of the distributed teams I’ve worked with recently haven’t even had access to basic communication tools like corporate Instant Messaging or wikis, let alone high-quality video connectivity.  If securing communications is an issue, perhaps IT departments should provide alternatives to using Twitter or Google Chat on personal devices for work communications?</rant>

**<rant>I spent a year working on a dispersed team for a huge multi-national project involving three different global companies where almost everyone worked from home, connecting principally by phone/email/IM.  While I loved the experience for personal reasons (baths at lunchtime!  jeans!  flextime!), I think it was disastrous for the project in how much it slowed down getting things done.  I spent almost all day on the phone dealing with things that would have taken a 10th of the time had we been colocated.</rant>

Meeting Expectations

A member of a team I’m working with recently observed that the team’s design workshops were much more effective when she (and everyone else) came to the meeting prepared with an agenda, examples of the problem space and some other concise reference materials related to the design discussions. Having this pre-work (and pre-thinking) in place made the meeting flow smoothly and helped participants understand the context for the decisions being made so that a lot of ground could be covered in a relatively short working session.

The observation that meetings will be more effective with some thoughtful preparation seems like common sense, but somehow I still find myself attending too many meetings that waste people’s time and energy because the intended outcomes aren’t clear and/or necessary info & decision makers aren’t in the room. I sense that because Agile favours lightweight processes and documentation, some teams have formed the impression that you shouldn’t be worried about things like agendas and preparing for meetings/workshops/whatever kind of group session, because you’ll do it all “just in time” (i.e. “making it up as you go along”); this is a misunderstanding, as Agile work practices place great value on identifying desired outcomes and how you’ll know you’re done before you dive in to a piece of work, as well as timeboxing work to help make sure that something of value gets delivered in the time available.

There’s a lot of really good advice on facilitating effective meetings readily available. I go back to Jean Tabaka’s book Collaboration Explained repeatedly for guidance on how to facilitate effective meetings while fostering collaboration and creativity. One technique from this book that I’ve had great success with is building agendas using a set of questions; rather than just identifying a topic for discussion, phrase the agenda item in terms of the specific question(s) on that topic that the group needs to answer. This technique has three advantages:
• people are prepared for what specifically needs to be discussed/decided
• there is an clear outcome to the discussion identified from the outset so that participants know when the topic is “done” for the meeting (“have we answered this question?”)
• it limits rat-holing by redirecting focus back to the specific aspect of the topic to be addressed
Agendas might also include timeboxes for each topic/outcome in order to keep the group on-track. It’s astonishing how much can actually be accomplished in a few minutes of discussion when the team is prepared and focused.

You can help tighten up your team’s meetings even if you’re not the meeting facilitator. Esther Derby provides a great list of suggestions that any meeting participant can implement to help improve meeting discipline, including :
• ask for an agenda ahead of time
• send only one person from your team
• politely decline the invitation
• offer to take notes
• facilitate from where you sit
• ask for progress checks
• help others participate
• summarize
Lastly, don’t be afraid to ask questions about the proposed duration of a meeting. Microsoft Outlook has conditioned us to schedule meetings in 30 minute increments, but different meeting purposes require differing amounts of time (often less than 30 min or 1 hour). Using arbitrary timeslots because that’s what the scheduling app gives you by default leads to Parkinson’s Law. Be bold and schedule a 15 minute meeting if you think the objectives can be met in that time. And rather than waiting several minutes to begin in order to accommodate latecomers, start your meetings right on time and end them after 25 or 55 minutes to allow participants time to get to their next engagement (of course, if your team is dedicated and co-located, this is a non-issue).