Tag Archives: agile

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

Posted on by
2

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.

distributed retrospectives with a twist

Posted on by
Reply

In  the traditional agile retrospective, everyone gets in a room and puts post it notes on a board.  The group then sorts the post its by topic.  Then there is discussion about the points brought up.  I find there are a few limitations with this approach:

  1. It requires everyone to be in the room at the same time.  This isn’t always easy.  (Especially if the team is distributed or partially allocated to other teams.)
  2. Everyone has to watch the sorting exercise.  Throwing more people at this doesn’t make it faster on a big team.
  3. People get worn out by the long meeting.
I’ve done about a dozen retrospectives where people write on post-its in advance of the retrospective and leave them in a shoebox.  (We’ve extended this to having the shoebox available for the length of the project so team members can add thoughts as they occur.)  We then have myself and another team member group the post its by category.  Then we use the actual retrospective meeting for discussion/brainstorming.  For members located remote, we let them e-mail post-it notes.  This loses the anonymity, but people haven’t seemed to mind.
At he end of the season, the programmers of Stuypulse do a  lessons learned over e-mail.  We had more new programmers this year that stuck with the team than ever before.  I wanted to make sure we got their input and the brainstorming wasn’t “biased” by older team members.  I suggested we do a retrospective.  It was an experiment for me too as I’ve never done one completely remote (or without post-its or a shoebox.)  Remember that these are high school students and it is likely they’ve never done any type of agile retrospective before.  Here’s what went down.

Phase 1 – post it generation

I searched if there was an online retrospective website and didn’t find anything.  [If anyone reading this knows of one, please post a comment.]  Instead of post-its, I created a google docs spreadsheet with the following columns:

  • green background – What did we do well?
  • red background – What should we do differently?
  • blue background – What did we learn?
  • purple background – What still puzzles us?
  • Division – I wanted to record whether the comments were coming from a programmer or someone in a different part of the team as perceptions were likely to be different.  This turned out to be a non-issue as only one non-programmer contributed content.  (Which is interesting because when we did lessons learned on the mailing list, we had lots of comments from engineers.  This may still happen in phase 3, but at least programmers got to frame the discussion about programming in the brainstorm phase.)
  • Optional name – In case there we wanted to clarify something.  Only one person choose to be anonymous.  This column turned out to help me because a week after I sent out the request to participate, only the more senior members of the team had contributed content.  This allowed me to “re-invite” the newer members by name.  If everyone was anonymous, I would have just known that turnout was poor but not why.

Phase 2 – post it sorting

Ina corporate environment, I just sort/group the post its.  With the high school team, I also edited a little.  Just to avoid “I agree with so and so” because the sorted post its don’t have names on them.  This took me about an hour.  I did not edit the items for length even though some contributes were sentences (which is really long for a post it note.)  I also added a couple post its to round out groups and get at missing subtext.  I’ve added post-its while grouping in a corporate environment too when the contributed post-its dance around an issue.  This is actually the first time I’ve grouped post-its without having an “other” kitchen sink category!

Now that we are ready for phase 3, the spreadsheet has three tabs:

  1. raw data – what people contributed
  2. grouped – data from tab 1 grouped by category
  3. a summary of the categories, # posts its in each category and a summary with some questions for discussion (in a corporate setting, I order the categories by # posts but don’t come up with questions.  I did here because phase 3 will be over e-mail)

Phase 3 – discussion

This hasn’t happened yet.  I’m sending the spreadsheet out today.  I expect it to be like the lessons learned e-mail threads of the past though.  Which is fine now that we’ve gotten the topics to talk about out there.

the trust cycle vs the hype cycle

Posted on by
Reply

Most of have seen the Gartner hype cycle graph – shown here from wikipedia.  This got me thinking about what would happen if we tried to do the same thing – except with trusting our teammates to see how they compare.  I’m calling that the “trust cycle.”  While we do hear a lot about trust and team in agile, the only place I found using the term “trust cycle” wasDavid Weiss’ blog.

The beginning:

With the hype cycle, we start at basically zero.  We haven’t heard of something and we remain skeptical until we hear a little.  Then we get too excited.

With the trust cycle, I think you start more in the middle.  When you first meet someone, you don’t inherently trust or distrust them.  And at the beginning, people are pretty cautious and don’t do anything to change that.

The middle

With the hype cycle, the trigger for change is reality.  We go from inflated expectations to seeing what the technology can really do.  Since our expectations were too high, we fall harder.

With the the trust cycle, the trigger for change depends on whether it is positive or negative.  For positive trust (teambuilding), it just takes time.  Our trust level slowly goes up until we trust the person fully.  For negative, the jump happens much faster.  Either as a series of little things that make you suspicious (as shown in the graph) or as one big thing that causes a series drop.  Once we’ve dropped, trust either stays at rock bottom or gets re-earned very slowly.

The end

Both cycles stabilize at the end.  The hype cycle stabilizes at reality.  The trust cycle stabilizes at either trust or distrust.

Conclusion

This stickyminds article talks about how to build trust.  What do you think about the trust cycle?