A few more comments on pair programming

In reference to my previous entry about pair programming, one other point that we discussed at the AgileKC meeting was recently brought up in two different projects.  The point was 'If you're ready to start pairing, don't over analyze the process. Set a date and time and start pairing.  Afterwards take a step back and review what you and your team learned.'

A new client of Visionpace needs to get a .Net project off the ground with their development staff, who are extremely capable. However they don’t have much .Net expertise or agile experience. We talked about what they were looking for and determined that our Perfect Coaching would fit the bill. At the client’s request, we’ll spend a day a week pairing with their developers. The other four days the client’s staff will work on the project pairing with each other. In addition we’ll help lead the first couple of iterations, so they can get a feel for the process. We conducted a user story work shop and spent two days with their developers going over TDD, our naming conventions, tasking user stories, etc. so we’ll have a common understanding when we begin pairing with the client’s development team. 

During this time one of their developers asked “How do we start pair programming without Visionpace being involved?”  I explained that given the way that they currently work (good report, little politics if any, smart people), they could begin pairing by selecting a user story, tasking it out, and then selecting one of the tasks and sit down with two developers and on computer and start working on implementing the task. Since it is a different approach and takes some getting accustomed to, I recommended that they set a time goal for pairing. Initially they should pair for two hours (minimum) ever day. After the two hours they could decide if they want to continue pairing or spend the rest of the day working solo. Over time this goal should be increased from two hours to four or more. The point was not to worry about if they were being as effective as possible when pairing at first. Rather just set the goal so they can become more comfortable with the nuances of pair programming. 

On a related note, in a different client project with two Visionpace resources (working from different cities) we came across a situation of ‘making sure we stay in tune with what the other team member is doing’.  Over the last two iterations both resources had days that they were taking off, other project commitments and the like. The end result was that they found themselves pairing less and talking more about what they were working on. We reviewed the situation in our iteration review meeting (the ideal time to tweak the process) and the two developers in question determined that they needed to have a couple of standing pairing sessions each week. The code and content of the sessions would be determined the day before the session. The content wasn’t the issue. The fact that they weren’t finding time to pair that fit both of their schedules was the issue. The resolution then was to set the time for pairing, and fill their schedules around it. 

Much like the previous situation, the answer to ‘how do we focus on pairing?’ was schedule the time and work the rest out as needed. By establishing the schedule parameters for pairing, you can remove a lot of the questions about when, where and for how long that might be present when looking to introduce pairing. The other facets of pairing (and there are many) can be addressed as they become apparent in the project with your team.

Some points from a recent AgileKC conversation

Last week I presented an overview of pair programming at the AgileKC group (www.agilekc.org) in Kansas City, Missouri, where I work doing software development and consulting. The presentation was well received and led to some pretty good discussion among the attendees about starting and/or furthering their pair programming efforts.  Out of the discussion, a couple of points were discussed that are worth sharing on this blog. So I thought I’d do so over a couple of entries.

The first point is:  to discuss and list out the goals with the team that are being pursued with pairing. These goals can be as specific as ‘Achieve 100% unit test coverage in the accounting business rules object by having one person in the pair write the test and the other person write the code’ or more general as ‘Have the current data access architecture evaluated by pairing on all tasks that involve this module.’ Whatever they are review them with the team so that the team can better understand what the focus of the process is in relation to the focus of the user stories. It’s also easier to determine if progress is being made toward the goals if everyone knows what they are up front.

This brings up the second point we discussed: make sure you allocate time to critique the process (pairing – what’s going well and what’s broken) independent of the iteration/project burn down. The team needs to know that they’ll have a chance to weigh in on how the work environment is going, and be part of any discussion to changes in the process. By doing this independent of the user stories discussions, it allows for a clearer review of the process. (You can isolate and discuss issues that are more related to the ‘soft skills’ associated with pairing, and not get into technical discussions of the work at hand.) This is directly related to the third item listed here.

The third item is: when you are moving from a solo based development environment to a pair programming environment, tread carefully. Organizationally you are changing the team dynamics and how people physically work. There are a lot of things that can cause problems in this regard. I’ll blog about this at a later date. Suffice to say, a good solid process is critical as well as an open mind, sharp eyes and a quick ear. I’m not necessarily addressing how management perceives pairing, though that’s equally important. What I’m talking about is that there will be a lot of different factors that most likely weren’t issues when solo-programming that may need to be addressed and/or worked on when pairing. Typically these issues are not seen or tracked by the project metrics. They are found by talking with the team and watching how they interact. By expecting that there will be some bumps along the road, and letting everyone know that the process will follow the ‘inspect and adapt’ mantra, there’s a greater chance that any issues can be resolved before they cause any damage.

I’ll post some more thoughts tomorrow. Let me know if you have any thoughts or comments by emailing me at molson@visionpace.com