Sunday, September 21, 2008

Coding Dojo demonstrating the power of reflect and adjust

Well I think the Coding Dojo last Thursday was quite successful despite some scrambling in the beginning.  Thanks to Matt Ryall for organising things at Atlassian and all the participants for showing up with really only one days notice.

From the discussion at the end, our current plan is to run these monthly so stay tuned...

There seemed to be quite a dramatic improvement after a quick retrospective we held in the middle so here's a shot of the board (also includes additions from the retrospective at the end) (click for larger version):


Works Well
Could be Better
  • Most people didn't know how to use gVim => switched to Dave's Mac + TextMate
  • The coding pair was too quiet so the audience doesn't know what's going on => Added a responsibility to the co-pilot to relay to the audience what's going on
  • Our crowd was mostly Java and .NET types and we didn't have enough familiarity with Ruby syntax, tools, etc.
  • Kept forgetting to switch pairs on time => zsh script + Growl = "Changeover now" audio signal every 5 minutes.
Puzzling
  • Should we try to control the input of the crowd?  As it was, there were periods of chaos, multiple discussions, and then focus, and then back.  On reflection, I think we liked that.
Things to Try For Next Time
  • Defnitely use some kind of timed audio signal for changeovers.  When I first tried this internally at ThoughtWorks we just used someone's phone.  The Growl setup was cooler but the important thing I think is that it's automated and aural.
  • The coding pair has to bring the audience along.  Co-pilot vocalising what's happening is one way to do that.
  • Setup the tools before hand.  So a dummy test that just asserts false or something.
  • Use a language environment enough people know at least moderately well.  Suggests that we should poll the attendees before the dojo session.
  • Multiple simultaneous sessions.  Versus style.  This could be alternative languages solving the same problem or an actual versus problem like RRobots or Robocode.
  • A warm-up kata for beginners.  Our crowd, although not the best Rubyists was actually quite experienced with TDD and pairing concepts.  From that perspective, it would be difficult for someone new to those concepts to follow what we were doing.  I'm thinking we could start with a warm-up kata and then transition to a second "full speed" session.

1 comment:

Matt Ryall said...

Thanks for running the dojo, Jason. I found it really interesting to do the exercise with frequent pair rotation.

Picking up a bit of Ruby was great, too.