For last week’s retrospective, we decided to focus on strategies to improve our performance as pair programmers. We chose the “Force Field Analysis” activity from the Agile Retrospectives book, an activity geared toward gaining insight. I was pleased to hear at the end of the retrospective, one of the newer engineers remark:

“In my fifteen years of software industry experience, this is the first bullshit team exercise where I have actually learned something”

There were six of us at Blazing Cloud on Friday, with Liah and Jen-Mei on vacation. We split into two groups, making sure that the two engineers who had been here the longest were in different groups and the two newest engineers were also in different groups. We then had 2 sessions, each 7 minutes long, where each group brainstormed things that would 1) drive and support better pairing and 2) inhibited us from becoming better at pairing.

Then we got back together and reported “round robin” from each team and I listed on the whiteboard (skipping over duplicates) with “drivers” on the left and “inhibitors” on the right. After that we talked about what we think would help or inhibit us the most and drew fat and skinny arrows.

“Even if you can’t be the one on the keyboard, you need to feel responsible for those lines of code.”

Drive / Support Better Pair Programming

• More Pairing
  • Pair should finish at least one feature (schedule for features, instead of allocating time in days)
  • Think about pairing partners when planning
  • Enforce/Plan Pair Programming
  • Pair overlap when shifting resources for on-going projects
• Get Advice
  • Ask Wolf to present his knowledge on the subject
  • Ask folks at Pivotal about their experience teaching pairing to new hires and best practices
• Talk more while pairing
  • Talk first about the problem/give overview of project, before starting to code or look at Feature/Issue Tracker
  • The person typing should vocalize what they are doing
  • Ask “is this a requirement? Is this the thing we should be doing?”
• Experienced person types as an intro, then less experienced person types when familiar with the project
• When brainstorming what approach to take, consider taking on different roles, such as one person looking up code and another documenting the plan that both are coming up with.
• Switch up Pairs
• Read books about PP — any suggestions here?
• Pay attention to the other peson
• Physical presence: pairs need to coordinate when they will be at the office
• Project Consistency
• Workstation availability
• Parallel research at the same time by mutual agreement, but consider reading the found document together, benefits and drawback of reading difeerent things
• Share experiences and talk to each other
• One person responsible for drawing outlines, and taking notes while the other is writing the code (driving)
• Write down strategy on paper before writing code
• Participants pay attention to the other’s state of mind/focus area
• If the partner is moving fast ask to slow down

Inhibits Pair Programming

• Lack of context
• Pairs working on different tasks
• Lack of attention
• Insufficient solo learning -> more experienced person is responsible for guidance:
  • More experienced partner should suggest books, blog posts, articles for less experienced partner for solo learning.
    
  • Note that less experienced programmer may still have specific relevant experience/reading to educate the more experienced partner and should feel obliged to recommend reading as well
• People using different tools
• Interruptions
• Noise

I closed the retrospective with a “three H” exercise. I handed out sticky notes and asked people to write down what they thought helped or hindered the exercise or if they has a hypothesis (idea) of what we could do better next time.

Help

• format of the exercise was productive
• Like that we broke into smaller groups and later brainstormed with the whole group
• Everyone seemed engaged
• Structure was great, very clear instructions
• Focused the team
• Made everyone think and work together
• Team have the same concerns that I do
• I like the visual effects of the arrows to demonstrate significance

Hinder

• Need larger whiteboard
• Need larger whiteboard, difficult to read
• Whiteboard difficult to read
• Could have had more time
• We see what is important on the board now, but unsure of how this will be enforced in the future
• Can’t read whiteboard
• Need a bigger whiteboard

Lacking flip charts or more whiteboard space, we used the back of the office door to post stickies, which worked quite well: