more techniques for making agile games remote friendly

Two years ago, I blogged on how make agile games friendly to remote/distributed teams, Last week, I went to a NYC Scrum User Group meeting and was inspired to repeat the exercise.

This time, I’m going through *how* you think about adapting games as well. The key is to identify the lessons the game is teaching and what makes it run.

Game 1: 60 steps in 60 seconds

Key lesson: the importance of self organized teams.

Description of in person game: The group is split into pairs. The “manager” of one pair gives the “worker” instructions – left/right/stop/go. They do this for a minute and count steps. It’s hard because there are lots of people walking around and the worker has no autonomy. Then the pairs repeat the exercise where the manager can give goals rather than literal steps.

My take: I’ve played this before. In fact, it was the first agile game we played when my team was new to Scrum and needed to see the importance of being self empowered.

Making it remote/distributed friendly: This one is hard. I used a similar idea with a puzzle. I made two puzzles and had people pair up to do them using the same technique as 60 steps in 60 seconds. In one, do exactly what is said. In the second one, provide more broad instructions. While I did this one in person, it is easier to adapt to remote teams. Just do online puzzles (like a children’s jigsaw) with screenshare. You’d want to use cell phones for the pairs to communicate and reserve the video conference/phone bridge for the instructions and discussion about how it went.

Game 2: The Name Game

Key lesson: People don’t multi task well.

Description of in person game: This site describe sit well (I didn’t actually play this game at the meetup because you had to choose two of four to play, but I have played a similar game).

Making it remote/distributed friendly: It’s the same game. There’s nothing inherently in person to this game. You can use screenshare for any charts you want to show

Game 3: Throw Throw Burrito

Key lesson: Working together provides better outcomes.

Description of in person game: This game was a variant of the party game throw throw burrito. The first round was the party game. Then we switched to invented rules with a more collaborative twist. The goal was to maximize the score. Finally, we brainstormed how to make it even more collaborative. (As an aside one of the people in my game noted that if your opponent misses when throwing the burrito at you, there is no need to throw it at them and hit. Just walk over and tap the person)

Making it remote/distributed friendly: This one I can’t make remote friendly. There’s no way to throw a stuffed burrito remotely. There’s going to be some like this. The key is to save this type of game up for team onsites. For example, my team threw ping pong balls at each other at on of our onsites. I mean we played catch until there was too much work in progress to sustain it.

Game 4: Deep Sea Adventure

Key lesson: Working together provides better outcomes.

Description of in person game: First we played the Deep Sea Adventure board game with regular rules. Then we played again with the goal of keeping all the players alive and maximizing the score.

Making it remote/distributed friendly: At first glance, this doesn’t seem remote friendly as it is a board game. But it definitely can. You can make an electronic version of the game board/pieces (on OneNote or an online whiteboard) and use a random number generator online to replace the dice. The players would interact with the OneNote or online whiteboard as they play.

Game 5: Space <something>

I didn’t play this one. It looked like it was about collaboratively building a spaceship by trading cards. I didn’t see enough of it to have an opinion on making it remote friendly.

Using Agile Games to improve meetings – the virtual/remote edition

This evening, I went to the NY Scrum User Group where the topic was “Using Agile Games to improve meetings”.

As the presenters went through the games, I thought about how they could be adapted for a virtual/remote team. I spoke about Virtual Scrum last year at a Birds of a Feather session. I’m doing a presentation/breakout session at Spring One on the same topic this year and looking forward to adding an agile game or two that applies to remote teams!

In thinking of remote equivalents, I wanted to preserve the sense of fun along with the message/goal of the game. Here’s how that went.

Story Cube

The Story Cube game involves rolling dice and talking about feelings based on the dice. For more, see this Story Cubes description. The only part of this that is physical is the dice.

As a remote alternative, I thought about having pictures with each of the images and using a randomizer to display some on screen. Then the talking would proceed the same as if the images are on the table.

Dana Pylayeva (one of the presenters) noted there is a phone app if you want to spend $2. (That’s a lot cheaper than the physical dice by the way.) We searched for it during the meeting and found Rory’s Story Cube app. Looks cute. With the app, you’d need one per site.

Feelings Game

The Feelings Game involves physical EMO cards with feelings listed on them. Each feeling has a number next to it. In response to a prompt, each person writes the number of a feeling on a post it. The post its are randomized then the group discusses. For more, see this Feelings Game description.

This time there are two parts to make remote. The feeling cards part is easy. You make a web page/powerpoint slide having a table with numbers and feelings listed. Or you have each site print a copy. Or you buy a set of cards for each site.

Then you need a way to anonymously share the number everyone chose. There are a number of online shared whiteboarding services. I like web whiteboard because you don’t even need to login to use it. What’s more anonymous than a site you can use anonymously! (you likely don’t want to use google docs or one note because either the author is tracked or the perception is that it is)

Fist of Five

Fist of five is a survey technique where everyone holds one to five fingers up at the same time. For more, see this Fist of Five description.

This is really easy to make remote. My team does “finger voting” frequently. Especially at sprint planning. We do thumbs up/side/down voting. We do story point estimate voting. (When we were a collocated team, we used planning poker estimating cards. When we became a distributed team, we used pointing poker for a while. Then we had a retrospective suggestion to use our fingers instead and it took.) We do voting from a multiple choice list to see what people think of design tradeoffs.

Anyway, finger voting is easy over video conference/Google hangout/etc as you see each other. if you can’t see each other, pointing poker is good for voting. You can set it up to use any options you want. So you can choose the numbers 1 through 5 instead of estimates and you have fist of five.

Ehab El-Badry shared with me this anonymous fist of five tool. Nice!

My Right and Mrs Right

In this game, the facilitator reads a story and the team passes legos left and right when they hear “right” or “left” in the story. Those words come up a lot. I couldn’t find the exact story used at the meetup, but a similar story is here. Then she asked questions about the story. And we hardly listened because so fixated on the legos. (It was also more complicated because she had everyone holding two legos and changing hands in addition to passing them. I think this was to make the task harder.)

Clearly we aren’t passing legos around remotely. But I think any sufficiently complicated task would work and have the same effect. It loses a tiny bit of the team bonding but that wasn’t the main point of this learning game; it’s about the shared knowledge/reference for why multi tasking doesn’t work. Ideas of remote friendly tasks to replace the passing of legos in a circle:

  • Put a paper clip in the left or right pile when you hear those words
  • Count the number of times left or right comes up (this might be too easy)
  • Count how many words are mentioned that contain three letters

Beautiful meadow

There’s lots of physical objects in this drawing game. There is a large paper, multiple colors of markers and a page of requirements. For the details/text of the game, see this beautiful meadow description.

We clearly need a shared document tool for this. We could use web whiteboard. For this game, there is no need to be anonymous so Google docs, OneNote or your favorite collaborative editing tool works. After splitting up the different groups into different shared document URLs, the moderator would drop the instructions into each board and keep time. Participants would have to be instructed to only communicate through the shared doc – no IM! But other than that, it’s equivalent.

Clapping/Raising hands

This was an unofficial game. “If you hear me, clap once” or raising hands to get everyone quiet. These work through phone or video chat respectively.

WIP Game

I can’t find an online reference for this game, but it is easy to explain. Half the group tries to write “I must limit work in progress” five times as sentences. The other half does the same but by writing “I” five times then “must” five times then, well you get the idea. About halfway through the time it would take to do this, the group is interrupted becuase the project ran out of budget and figures out who can deliver full sentences.

The only thing to change for remotes is to determine who uses which approach. Physical colored cards don’t work. But counting off or a random number or anything else to split up the two halves works.

Constellations

An object forms the center of the room. Then questions are asked and people move closer or further away. For more, see this Constellations description.

I’d make this remote by using a collaborative editing tool like web whiteboard, Google docs or OneNote. I’d either put an image on the center of the whiteboard or draw a giant dartboard. Then I’d give people a color to use to represent them or type their initials in the spot where they would “stand”

Candyland

I can’t find an online reference for this game, so I’ll describe it. We stood in pairs in front of colored pairs. We spent a minute talking about what we learned and then moved X spaces.

I think this is the most challenging to make remote friendly, but it is still possible.  At the beginning, have everyone pick a number. Randomly or by choice. Then have #1 and #2 chat, #3 and #4 chat, etc. After a minute, have the numbers shift.

Conclusion

Being on a remote/virtual team often requires a little imagination. But it’s fun. And easier than you might expect to adapt to.

the effective remote developer – live blogging at qcon

The Effective Remote Developer
Speaker: David Copeland @davetron5000

See the list of all blog posts from the conference

David has worked for 4 years remotely. Most people are remote.

Definition of remote

  • “You are remote if you do not often interface face-to-face with the people you work with”
  • hard – lone wolf – only one person is remote
  • easy – everyone is remote
  • also – multiple offices

Definition of effective

  • Productiving value
  • Agency – don’t just want to be closing jira tickets
  • Inclusion – don’t want to be that guy in Alabama that people send work to
  • Rewarding

Not easy; takes constant upkeep

Benefits

  • Freedom & flexibility – no commute, acccess to own kitchen, live where want
  • Company has access to wider pool of talent – slowing down ability to liver by restricting to specific area

Must build with people you don’t know and maintain trust with people that don’t.

Trust

  • “the half life of trust is six weeks – it must constantly be replenished”
  • Communicate frequently and clearly – Turn big projects into small ones. Everyone knows what working on. Get early feedback. So shows value delivering. Provide more context. Read what wrote and revise at least once. Use bold/underline/whitespace for clarity.
  • Be responsive, but set boundaries – publish your working hours (including time zones). Put in email signature and comment if meeting outside working hours. Developer a worklow where you aren’t heads down coding for hours; develop mental SLAs for communication. Specific affirming (positive) feedback is useful.
  • Assume good intentions – we are not good at critiquing. remember the reviewer is trying to help even if sounds cold and harsh.
  • Help others help you – go to chat or video for people who don’t communicate well over emai. Find out how everyone best communicates. Be specific in what type of feedback you want

Base level of technology

  • Easiest thing, but need to be successful
  • Chat system that is easy to use
  • Video conference that supports multiple people
  • Better mic than laptop mic

Types of communication

  • Coding – Think about smallest viable change. Write better change requests so can judge your changes. Learn to screencast (quick video) and diagram.
  • Synchronous – ex: video chat. Experience people as a human when not present. Be prepared. Formulate opinion in your mind. Use nouns instead of pronouns more than you think in case a few words drop. Also, pause more frequently and ask for feeback. “Any questions before I move on”. Don’t multitask; pay attention – best case is missing info; worst case is getting called out or having to ask. Have regular backchanel for tech issues.
  • Asynchronous
  • Socializing – If quiet in office, people still know who you are and that humanizes you. If remote, you are a producer of emails. Use time before meeting starts to socialize. Have one on ones with no agenda. Like scheduling time to stand around the water cooler. Travel to meet others in person. Accept that will miss happy hours

Remember computers are terrible and nothing works. Can bond over shared bad experience.

When interview, do chat and give take home project (add a few features) then pair program remotely to add another feature. Then fly onsite to interview. Have hired a few without flying in

Dedicated area at home to work.

Many of these tips are helpful even without remote developers.