virtual scavenger hunt

Today at work, my team did a virtual scavenger hunt. I got the idea online, but I don’t remember where. What we did

Make the list

I had everyone post in the group chat one item to find. (I did this rather than making the list so I could play too!). We had:

  • a toy
  • toilet paper
  • a can of food
  • hand sanitizer
  • lysol
  • winnie the pooh
  • a book with exactly 8 words in the title
  • chocolate

Find items

Everyone then went off and got items. IT was fun int he video conference as people walked by with their stuff.

Show and tell

I then said each item and we held up what we had for that item. I combined hand sanitizer/lysol into one item. We chatted about some items. It was fun

In conclusion

Today I had a work task to find toilet paper. How many people can say that?

github – one of your dependencies has a security vulnerability

Yesterday, I committed a new project to github. I wasn’t paying attention and made a (mental) typo in typing the jackson-databind version number. I typed 2.2.3 instead of 2.10.3. The former is an old version with security vulnerabilities.

This meant I got to try out a new feature I had only read about – github informing you about the security issue in a dependency. Looking at the repo, I saw a nice yellow box – “We found potential security vulnerabilities in your dependencies. Only the owner of this repository can see this message”

GitHub also created a pull request offering to “Bump jackson-databind from 2.2.3 to”. I chose not to accept the pull request and choose the later version I intended – 2.10.3.

After pushing that change, the yellow box went away. GitHub even noticed that I updated the pom.xml and closed the pull request with the message “Looks like com.fasterxml.jackson.core:jackson-databind is up-to-date now, so this is no longer needed.”.

I then went into my gmail and deleted the 18 emails with the subject “One of your dependencies has a security vulnerability.” All of these emails arrived within two hours after I committed. That’s way too many notifications!

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.