People Stuff Is Hard
Topic Overview: People Stuff Is Hard, Can't We Just Buy a Cricket Bat?
Convenor or Lecturer: Paul Field
Participants:
- Diana Larsen
- Rob Godfrey
- Dave Thomas (for about 30 seconds
 )
<various others whose names I didn't capture - please add yourself, correct any 'someone's in the text below and add any other comments that I missed>
(if you put your Namepage here, people can click to see how to contact you.
Session Notes:
Diana observed that drilling holes in the cricket bat was helpful.
Later on, Dave popped in for 30 seconds to observe that rubber tubing was a better option. <someone> told a story of his team who thought that one team member was extremely introverted and wouldn't take to agile. However, it turned out that everyone else had actually been too introverted to talk to that team member  Rob observered that when the analysts were brought onto the same team as the developers, it created a lot of stress for the analysts because the developers kept asking them lots of questions and they weren't used to it. Diana observed that introverts are often very good at one-to-one communication and so often work well in pair-programming. Paul mentioned that he'd seen different kinds of pairing. A mentoring pair forms when the level of experience is different between the members of the pair and one member wishes to learn. Other kinds of pairs form too, for example, two experts pairing to solve a really difficult problem. Paul mentioned that he had scaled up mentoring pairs - to get new members of the team up-to-speed; he had been the mentor in a quad-programming session, where 4 people had implemented a piece of functionality together with the major aim of learning about the system.
Paul told a story about the Retrospective Prime Directive, used in a different context. His support team are in India and initially he provided them with software tools and a step-by-step process for monitoring the system and resolving problems. They failed to follow it which was very frustrating - after all, it's a step-by-step process: what idiot can't follow that. After reading the prime directive, he decided to assume that the support team were very competant people but that something stood in their way. Now, all production problems to go via the team and, if they can't deal, they contact his team. But his team don't act as 2nd line support; instead they engage in "pair support", where they pair up with a member of the support team and mentor them through solving the problem. The support team member is responsible for passing on that knowledge to the rest of the support team. The first time this happened, it was with Paul and Ravi, the most junior member of the team. Afterwards, the support team manager contacted Paul to tell him how excited Ravi was about telling the other team members what he'd found out. Since then the team have started dealing with more and more difficult problems; including ones that require real problem-solving skills, not just a step-by-step process. Diana (I think) observered that bringing people together in one place (when geographically distributed) is often considered "too expensive" and it's very difficult for us to quanitfy the benefits even though they might far outweigh the obvious costs. The support team story shows that an obvious cost (the extra time invested by the development team in acting as mentors rather than just fixing the problem) can lead to significant non-obvious benefits. Rob observered that when developers make their own estimates for tasks they get a sense of ownership of that estimate and are more likely to put in extra effort to do that task to the estimate than if someone else makes the estimate. Interesting references that were mentioned:
Promiscuous Pairing Peer Code Review | 