[LRUG] The codes
brent at fuglylogic.com
Thu Sep 10 14:00:34 PDT 2009
First off, thanks to everyone who organised last night. It was really
valuable and a lot of fun. I was on the pirate team. Yaaaar. Rum. etc.
Matt's kata worked really well, it did a great job of guiding you
through in small steps. We didn't realise it was committing changes
when the iteration was passed but that was a nice touch.
Here's my observations:
Something that seemed really hard to manage was communication between
the peanut gallery (awesome term) and the pair. Like Taryn mentioned,
everyone calling things out can be really distracting when you're the
one under the spotlight. It becomes quite different from normal
pairing where you're focused on just the task at hand and what your
pair is doing; trying to either ignore or take on the suggestions of
everyone else as well adds an extra dimension of difficulty. One
concern is that it might make pairing seem harder or more stressful to
newcomers than it really is. It would be interesting to hear how
people felt being up there, especially people who haven't paired
Input from other people in the team is essential but I was thinking
about ways to incorporate it without affecting the flow of the current
One extreme approach would be to ban the peanut gallery from saying
anything to the pair unless it is solicited. If the pair is stumped
they could indicate that they want some help and people could chime in
(stick a hand up, whatever). I think an interesting side effect of
this would be that more people are motivated to get up and have a go;
the way to get your opinion heard would be to jump in line for the
next rotation. Any potential problems with this?
Another way to get people up and pairing might be to have the driver
rolling off the pair touch someone else on the shoulder as they sit
down. This would ensure that someone was always ready to roll on and
keep the rotation smooth.
There really is a world of difference between being in the audience
and being in the active pair. I felt like I was struggling to
understand how the simple bit of starting code while I was up there.
When I got to sit back down and digest it at my own pace it was a
One thing I don't understand is how the entire team is supposed to
work together to solve the problem - do you try and act like a huge
gestalt entity or is investigating in parallel OK?. When you're in the
audience, should you be following the progress as closely as if you
were in the pair? Is it bad to form to do otherwise? I'm not sure; I
lost track of the direction many times and felt a bit guilty but I was
also having some really interesting discussions with people around in
If it is OK to be approaching the problem in parallel then it would be
great to be able to try stuff out on your own laptop and then bring
the learnings into the pair when it is your chance to go up. A few
times I found it frustrating because I could only see the code that
the pair had open; I wanted some way to look at the other parts of
what they were working on.
If you're supposed to be working like a giant pair then I'd suggest
that groups of around 6 people might work a lot better.
It also seemed really hard to maintain flow when people are rolling
off every 5 minutes. I don't see this as a problem with the timebox
period, rather than we need a better way to maintain direction. The
really interesting effect of this was that it reproduced a problem I'd
seen in other teams that rotated pairs frequently (several times a
day); getting people up to speed and explaining/maintaining the
direction took up valuable time.
One thing that helped us when we had this problem was to maintain a
fine-grained TODO list for the story. Maintaining this list was the
navigator's job and our first task of the day was to review/refresh
the direction we were going. A new person on the story could be
brought up to speed very quickly by going through the current list. We
also had the added benefit of knowing when we were "done" at a higher
level. Changes to direction meant changes to the physical list so we
were forced to think a little more about them before making any.
I was wondering if something like this could be applied to the dojo as
a way of maintaining direction and reducing thrashing with the
frequent rotation. It might even also be a discipline you'd want to
represent formally in the dojo along side of pair programming.
Finally, I want to suggest something for people to reflect on. Try the
same kata on your own; try not to be influenced by the solution your
team came up with.
- how long did it take you?
- how did it differ from your team's result in term of approach or time taken?
- if it was different, why do you think that was?
- push your results and your observations so everyone can have a look
More information about the Chat