Archive for the ‘Distribution’ Category

In a previous post I shared my wonderment of how teams work hard to reach peak performance when they cannot see each other in the gaming world.

I see great synergies here with Agile – how different is it when software development is done in a distributed or offshore manner? Let’s take a look at the techniques gaming guilds use to reach peak performance.

ALWAYS use voice communications

Lucky you didn't see my avatar handle!

I know of no guilds that have any degree of moderate success without using either Teamspeak or Ventrilo. For those of you unfamiliar with these programs they are like Skype, but allow whole teams to be together in the same chat channel (or in various channels on the same server) without the video input/output but with amazing audio input/output. The reliability and quality of people’s voices is incredibly high. I would recommend that everyone in the team stays in the channel together as they work throughout the day. If you need to ask someone a question they are only a single button (microphone on) away.  Setup your channels something like the following:

  • Team (the default channel which everyone should be in)
  • Private meeting 1 (only if the meeting really has to be private – what is wrong with having the discussion whilst in the default channel?)
  • Private meeting 2 (see above, contingency channel)
  • Quiet Time (for when you really have to concentrate and not be interrupted by someone’s voice)
  • AFK (on lunch or bio break)
Basically you use these tools as an open-ended, incredibly cheap (both on bandwidth and cost of an instance), high quality conference call. What’s to lose?
Now I know with a 100% certainty that verbal imaging would make this even better, but the above solution has no end timeframe on the communication and is not heavy on a computer’s bandwidth. I have found Skype to be unreliable and questionable on quality and so for the moment prefer the audio.

Be present in time together

 This is going to be the hardest thing for offshore teams. I am going to put this out there: If you are doing offshoring to save money (which is a fallacy, but that is a different debate) then your partner must come to the table and provide optimal customer service. To do this they must work the same hours as the onshore team. This should not be a choice – this should be your requirement.

To put this into context – if someone from Australia wants to raid with an American guild they need to change their sleeping patterns and inconvenience themselves for the benefits that they perceive they will get out of it.

Fail often, reflect and adapt often

Who would have thought that gamers did this better than Agilists? In the gaming world, working together the feedback loop is incredibly tight. From failure to reflection of what went wrong is minutes, if that. Teams question what went wrong, search out the root cause and devise a plan to solve or mitigate the problem. The time from failure to another attempt is usually only another few minutes. The cycle continues with more information until the objective is met.

Use visual cues

Agilists do this somewhat better but probably more due to opportunity of the environment then anything else. In the gaming world special icons or symbols are used to indicate assignments, zones to move to, or behaviours to be aware of. This maps to some degree to story walls where tokens and avatars are used to denote particular significance – ie blocked cards, allocations, risks, expedites, etc. Unfortunately for distributed teams a number of tools out there don’t support tokens very well, but avatars are generally a standard feature.

Keep informed on best practice and alternative approaches

Gamers definitely do this considerably better. Because everyone is not together and because their objectives are difficult it is not uncommon for gamers to be given assignments to watch videos of similar people tackling the same issues, to seek out alternative approaches to reach objectives and to orient yourself to what can be expected. I liken this to regular upkeep of best practice of skills and new and innovate ways to approach the problems on your project. Ask your team – how many hours do you spend continuously improving yourself and the way in which you work in your private time – this is a great indication of how attuned the team is to their cause.

Read Full Post »

Most people in the Agile community are now familiar with the Marshmallow Challenge where the primary purpose is a lesson in collaboration and communication (according to the website), but for me the key takeaway is the need to prototype and fail early.

In one of the post events in Agile Australia 2011 Thoughtworks took a different slant on the game and applied a twist of seeing what happened if you distributed it. Rixt Wiersma was the co-creator of the game and I was lucky enough to have a talk to her before and after the challenge.

Taking what was used in that event and then adapting it even further creatively I have an advanced version of this game whose sole purpose is to teach to distributed teams the impact on communication rules and outcome. The result of this is below.


Time required: 20 minutes actual game play, 10 mins setup/explanation time, 5-10 minutes debrief.

Participants: Six teams of preferably four, but can be scaled up. If you have less than 24 then reduce team B and then D.

Materials: In addition to the standard Marshmallow materials, a notepad with removable paper and a pen is required. Team E will require two working mobile phones.


  1. Read the standard Marshmallow rules. Additionally;
  2. Inform the teams that the point is not to learn about prototyping early, it’s about learning the impacts of distribution. As such they need to feel comfortable to use the Marshmallow early in the challenge.
  3. Teams A-E are split in half, the first half is called ‘Alpha’ and second half ‘Beta’. Change the names to cities if you want.
  4. Setup varying distribution limitations on communications:
  • Team A: No collaboration even at minute 0. Beta is removed from the room immediately. No crossover time allowed, no communication allowed on switch overs.
  • Team B: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. No crossover time allowed, no communication allowed on switch overs.
  • Team C: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. No crossover time allowed, communication on switch overs is allowed but only via notes.
  • Team D: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. The teams are allowed to talk for 30 seconds at the beginning of switch overs.
  • Team E: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta asked to leave the room or move to the other side of the room. Alpha and Beta are allowed to observe the other team via other communication methods – this can be done either via a video/tv hookup or simply by letting them stand at a distance and listening in over a phone.
  • Team F: Alpha and Beta are never split.

Timings: Switch overs between Alpha and Beta happen at minutes 7, 12, and 17. At minute 17 the team being swapped out can observe the outcome of the last 3 minutes (in silence).

The crux: Introduce a requirement at minute 10 to not just have one point with the marshmallow on top but to have a second point at a similar height (ie two towers as part of a single structure). You might need to up the spaghetti sticks to allow this to happen from the norm.

Read Full Post »


Get every new post delivered to your Inbox.

Join 920 other followers