XPday London

Average Time To Green Game

Session Title: The Average Time To Green Game

Submitters: Jon Jagger, Olve Maudal and Kevlin Henney

Abstract:
Mary Poppendieck writes
Deliberate practice does not mean doing what you are good at; it means challenging yourself, doing what you are not good at. So it's not necessarily fun.
Peter Norvig writes
The key [to developing expertise] is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again.
The Average Time To Green Game is a game designed to increase software developers personal and technical agility by hosting challenging, deliberative practice. This can cause discomfort, which will hopefully be balanced by the fun of the game and the learning derived from it. The game is based on strict adherence to TDD ritual and requires at least half the attendees to bring a laptop. A game requires a minimum of 2 hours, ideally nearer to 3 hours.
Game masters
  • Jon Jagger
  • Olve Maudal
  • Kevlin Henney
Game setup
  • Each laptop is given a name (eg Canada, Spain, Greece, India, etc).
  • Minimum of two people per laptop.
  • Each laptop must have a TDD framework installed.
  • Each laptop remains at the same physical location throughout the game.
  • Electronic transfer of information between laptops is strictly forbidden.
Game heartbeat
  • Every 3-5 minutes a sound goes off (e.g., a cow mooing).
  • When the cow moos rotate the keyboard driver at each laptop.
Game iteration
  • Each iteration has a single clearly stated goal.
  • The goal should be something that is just beyond the participants current ability, something they are not good at. (The game masters will remind the participants of this point.)
  • Everyone (including the game masters) discusses the previous iteration.
  • The goal for the next iteration is chosen. The goal is often the same goal as the previous iteration. An important part of practice is repetition.
  • Swap partners and move to a new laptop.
  • The game masters ring the Average Time To Green Bell to signal the start of the next iteration.
  • Everyone lifts the green cover from their laptop screen and keyboard.
  • ...the iteration is underway...time passes...
  • 10-15 minutes later, the game masters ring the Average Time To Green Bell again, to signal the end of the iteration. They also start a timer and project it so everyone can see it. This timer starts at zero and increments second by second.
  • The aim at your laptop is then to get to green (all tests passing).
  • Once your laptop is at green:
    • write down the time it took to get to green since the bell (simply look at the projected timer),
    • give this number to the game masters, (they will record it in a spreadsheet),
    • cover your keyboard and screen with a sheet of green paper (provided by the game masters) and leave it covered,
    • wait until all the laptops are at green.
Game exercise
  • There will always be a specific current exercise (e.g. the bowling game kata) but this is not the main point of the game.
  • The aim of the game is to host deliberative practice.
Game goal
  • The first goal is always simply measure the average time to green.
  • The second goal is usually to reduce the average time to green.
  • The third goal is often to control the average time to green.
  • ...
  • ...subsequent goals could be...
  • ...
  • a specific refactoring.
  • written feedback from/to each pair-partner.
  • 100% compliance to the write-the-test-first rule.
  • a new exercise.
  • change the game heartbeat period.
  • retire a random laptop from the game.
  • change the language on one laptop.
  • change the language on all laptops!
  • change the game iteration frequency.
  • choose a new unseen goal from a stack of goal cards!
  • ...anything you can think of...
Back to Submissions page

Comments

From 81.31.112.23 - 2009-09-25

Hi Rachel,I have run it yes, and will be running it again in a few weeks time. The only time box I think I mentioned is 3-5 minutes but this is the period between keyboard swaps. The time between iterations is longer, typically 10-15 minutes. (I will amend the wording to make this clear if it isn't). It is important to remember that the first exercise is deliberately very very simple; the aim of the game is not to improve "technical" skills per se. Only when the players have realized that the game is a vehicle for deliberate practice might it make sense to consider more difficult exercises. Hope this helps. Jon Jagger

From Rachel Davies [212.84.97.237] - 2009-09-03

I would like to know if you have run this session before. The timeboxes seem very short and this could be quite chaotic which might put people off learning.

From 81.31.112.23 - 2009-08-10

What you have suggested could indeed happen. And has happened! There might be one or two developers who, initially, do not truly appreciated the nature of the game and do not think about the effects of their actions on the other pairs. During the very early iterations the other pairs are sat ready, at green, with their keyboards covered and eventually (perhaps after some gentle prodding by the game masters) the unaware pairs realize they are holding everyone! They promptly change tack and abandon everything except getting to green. It can be a somewhat uncomfortable direct learning experience! (There will be more!) There is then a mini retrospective where the iteration is discussed (both in the technical sense and the "process" sense) and the next iteration goal is decided (often with some prodding by the game masters). In practice, the enforced pairing, splitting of the pairs and swapping computers rapildy spreads strategic and tactical knowledge through the entire room. They rapidly get to the point where they are actually in control of the development process (and not vice versa) and this frees up mental capacity to start true "live" reflective learning. I hope this helps to answer your query...

From Matteo Vaccari [93.68.19.253] - 2009-08-10

The way the game is described, it looks like you keep piling broken tests until the end of the iteration, when the bell rings and you must scramble to make them pass.  Could you clarify that this is not what the organizers expect?  Or is it just me misreading the description?

Page

New
Edit
Rename
Versions

Menu

Edit Menu
Versions

Site

Changes
Index
Search
Templates

User

Log In

 
 

Last Modified 2009-09-25