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.

[2018 oracle code one] evolutionary architecture in agile environment

Evolutionary architecture in agile environment

Speaker: Xavier Rene-Corail

For more blog posts, see The Oracle Code One table of contents


  • Not that we don’t have a plan. We have a plan. But it can change
  • Emerging design – do have a high level design. Not chaos
  • Things change. There’s nothing that will not change. Make easy to change the things that will/might.
  • Prototype architecture. Working software over comprehensive documentation. Architects shouldn’t deliver paper docs

Software architecture is

  • “the important stuff (whatever that is)” – Ralph Johnson
  • finding internal *abiities
  • managing conflicting *abilities and determining which is most important

Agility is

  • ability to move quickly and easily – Oxford dictionary

Evolution of architectural styles

  • Monolith – not scalable, single point of failure
  • Layered – defacto standard for JEE apps
  • SOA – natively scalable, but cn turn into monolith
  • Microservices – now need orchestration
  • Severless – abstract more

Beware of

  • Dependency hell/service dependencies
  • Distributed transactions


  • Minimize coupling
  • Couple fro highly changing to infrequently changing
  • Ask users for feedback. Don’t overarchitect
  • Feature flags. Make safe to fail
  • Eat an elephant one bite at a time. Design that way too

Decide up front – programming languages and frameworks. These are difficult to change.

My take: Good session. My notes are “less good” because I was eating lunch during the design principles. So listening, but not blogging! 

another agile game virtual/remote team style – circle connections

Last year, I wrote about Virtual/remote friendly agile games. Yesterday at the NYC Scrum user group, we played an agile game about circle connections. The game was:

  1. Stand in a circle with the people at your table.
  2. Everyone picks two people (but don’t say who they are)
  3. Keep moving until everyone is equidistant from their two partners.

The idea is to show how chaos lessens and equilibrium is achieved. Ok.  Physical movement. Can we make that virtual? Actually yes!

Using a tool like togetherjs’s drawing tool, you can see everyone’s cursor. So all team members can move around the cursor to meet the equidistant requirement.

Not just any collaborative editing tool will do. It needs to be one like the drawing tool which displays all the mouse cursors!

We also played a game where we built towers with newspaper. That one I don’t think I can make remote team friendly!