[LRUG] The codes

[Alex Scordellis]

>
> 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?

I've seen a similar format work exceptionally well in a discussion
forum situation:
* there are 4 chairs at the front of the room
* 3 are occupied
* the 3 people at the front are allowed to talk
* if you're in the gallery, you're allowed to ask questions to the panel
* if you're in the gallery and want to answer a question, or
contribute anything more than a question, you have to go and sit in
the empty chair
* when someone sits in the empty chair, one of the 3 other panel
members has to return to the gallery

I'm not sure how well this would work for a programming problem, where
continuity is perhaps a bit more important. Perhaps if you have
something to contribute, you go up and sit in a third chair next to
the pair, and they bring you in at the next break in their flow. Which
is kind of what Brent suggested I guess.

In the ninja group, the pair weren't able to speak loud enough for the
whole group to remain engaged in their thought process - the group was
too spread out physically. So +1 for smaller groups.

I thought the BDD loop rake task worked really well. I did find myself
wanting to write intermediate additional tests. For example, in
scenario 2 (1*1\n111), I wanted to write a test that the *
representing the mine appeared in the right place, before supporting
the 1's. I'd consider this a unit test rather than an acceptance /
functional test. So if I get some time today, I might fork the repo
and add a hook point for the coders to add rspec (non-cucumber) specs
as an intermediate point.

Thanks to everyone involved - I had a great time. That was my first
LRUG meeting so whoever's up next month has a high standard to live up
to!

Alex

2009/9/10 Brent Snook <brent at fuglylogic.com>:
> Hi everyone,
>
> 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
> before.
>
> 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
> pair.
>
> 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
> infinitely easier.
>
> 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
> the meantime.
>
> 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
>
> Cheers,
>
> Brent.
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>