Hi all!!<br><br>I also was in the Pirates group.. yay!! Unfortunately, I have to disagree with those who say that the peanut crowd (or whatever is called) should let the pair develop... I'll try to explain it, although english is not my first language so, please, be patient ;)<br>
<br>I think that the pair, instead of trying to progress in the problem by themselves should stop and gather ideas from the peanuts, in order to find the path to follow. Why? <br><ul><li>[[Off-topic: I love bullet points]] Pirates is the team, not the pair in front of the laptop.</li>
<li>To avoid the snowball effect (if that makes sense...). Because, you might be developing the 5 minutes you are in front of the laptop, but your actions will affect the other guys that will follow you.  So:</li><ul><li>
If you do things right, you will help the guy after you.</li><li>If not...</li></ul></ul>So, I think the best way to begin is by defining some guidelines and this implies the first guys won't probably code anything.<br>
<br>That's it guys, hopefully someone will agree with me :)<br>Jordi.<br><br><br><div class="gmail_quote">2009/9/10 Brent Snook <span dir="ltr"><<a href="mailto:brent@fuglylogic.com">brent@fuglylogic.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi everyone,<br>
<br>
First off, thanks to everyone who organised last night. It was really<br>
valuable and a lot of fun. I was on the pirate team. Yaaaar. Rum. etc.<br>
<br>
Matt's kata worked really well, it did a great job of guiding you<br>
through in small steps. We didn't realise it was committing changes<br>
when the iteration was passed but that was a nice touch.<br>
<br>
Here's my observations:<br>
<br>
Something that seemed really hard to manage was communication between<br>
the peanut gallery (awesome term) and the pair. Like Taryn mentioned,<br>
everyone calling things out can be really distracting when you're the<br>
one under the spotlight. It becomes quite different from normal<br>
pairing where you're focused on just the task at hand and what your<br>
pair is doing; trying to either ignore or take on the suggestions of<br>
everyone else as well adds an extra dimension of difficulty. One<br>
concern is that it might make pairing seem harder or more stressful to<br>
newcomers than it really is. It would be interesting to hear how<br>
people felt being up there, especially people who haven't paired<br>
before.<br>
<br>
Input from other people in the team is essential but I was thinking<br>
about ways to incorporate it without affecting the flow of the current<br>
pair.<br>
<br>
One extreme approach would be to ban the peanut gallery from saying<br>
anything to the pair unless it is solicited. If the pair is stumped<br>
they could indicate that they want some help and people could chime in<br>
(stick a hand up, whatever). I think an interesting side effect of<br>
this would be that more people are motivated to get up and have a go;<br>
the way to get your opinion heard would be to jump in line for the<br>
next rotation. Any potential problems with this?<br>
<br>
Another way to get people up and pairing might be to have the driver<br>
rolling off the pair touch someone else on the shoulder as they sit<br>
down. This would ensure that someone was always ready to roll on and<br>
keep the rotation smooth.<br>
<br>
There really is a world of difference between being in the audience<br>
and being in the active pair. I felt like I was struggling to<br>
understand how the simple bit of starting code while I was up there.<br>
When I got to sit back down and digest it at my own pace it was a<br>
infinitely easier.<br>
<br>
One thing I don't understand is how the entire team is supposed to<br>
work together to solve the problem - do you try and act like a huge<br>
gestalt entity or is investigating in parallel OK?. When you're in the<br>
audience, should you be following the progress as closely as if you<br>
were in the pair? Is it bad to form to do otherwise? I'm not sure; I<br>
lost track of the direction many times and felt a bit guilty but I was<br>
also having some really interesting discussions with people around in<br>
the meantime.<br>
<br>
If it is OK to be approaching the problem in parallel then it would be<br>
great to be able to try stuff out on your own laptop and then bring<br>
the learnings into the pair when it is your chance to go up. A few<br>
times I found it frustrating because I could only see the code that<br>
the pair had open; I wanted some way to look at the other parts of<br>
what they were working on.<br>
<br>
If you're supposed to be working like a giant pair then I'd suggest<br>
that groups of around 6 people might work a lot better.<br>
<br>
It also seemed really hard to maintain flow when people are rolling<br>
off every 5 minutes. I don't see this as a problem with the timebox<br>
period, rather than we need a better way to maintain direction. The<br>
really interesting effect of this was that it reproduced a problem I'd<br>
seen in other teams that rotated pairs frequently (several times a<br>
day); getting people up to speed and explaining/maintaining the<br>
direction took up valuable time.<br>
<br>
One thing that helped us when we had this problem was to maintain a<br>
fine-grained TODO list for the story. Maintaining this list was the<br>
navigator's job and our first task of the day was to review/refresh<br>
the direction we were going. A new person on the story could be<br>
brought up to speed very quickly by going through the current list. We<br>
also had the added benefit of knowing when we were "done" at a higher<br>
level. Changes to direction meant changes to the physical list so we<br>
were forced to think a little more about them before making any.<br>
<br>
I was wondering if something like this could be applied to the dojo as<br>
a way of maintaining direction and reducing thrashing with the<br>
frequent rotation. It might even also be a discipline you'd want to<br>
represent formally in the dojo along side of pair programming.<br>
<br>
Finally, I want to suggest something for people to reflect on. Try the<br>
same kata on your own; try not to be influenced by the solution your<br>
team came up with.<br>
- how long did it take you?<br>
- how did it differ from your team's result in term of approach or time taken?<br>
- if it was different, why do you think that was?<br>
- push your results and your observations so everyone can have a look<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Brent.<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br>