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