Agile & Pair Programming: Scary but Necessary
Is it really a good idea to team up two developers to work on the same piece of source code, actually sitting together and watching one another type?
Programmers are known by some for being introverted loners, sometimes lacking social graces. They're known by some as artists, extremely touchy about their code and style. They're known by some for keeping strange hours, sometimes churning out their best artistic creations in long, caffeine-fueled, late-night coding jags with who-knows-what screaming through their headphones. They're known by some as -- ahem -- practicing questionable hygiene.
And you're going to tell them that the company is going Agile and adopting one of the major tenets of that methodology, pair programming -- and the fat older guy with the ponytail is going to be married to the young skinhead dude representing with all the tats for the duration of an important project piece?
Really?
"It is scary," admitted Dr. Mark Balbes, vice president of Architecture at Asynchrony, during a new webcast titled "Stories, Pair Programming & More: Top Must-Have Agile Techniques/Best Practices," hosted by ADTmag.com editor-at-large John K. Waters.
"It's scary because there's somebody that's right there who's going to be looking at your code while you're thinking," continued Balbes, author of the popular The Agile Architect column on this site. "And you don't have the opportunity to sit in a cube somewhere and tap out your code and refactor it and rewrite it and only when you're done -- and you're proud of it -- handing it off to somebody else for a code check. That pair is sitting right there watching you type every character. And it takes time to get used to that."
The key to acceptance is conveying to the team the exciting opportunity the methodology presents, Balbes said. The Agile coach needs to explain to the teams how fast everyone is going to be learning from everyone else. Knowledge of a tool or technology transfers to others much more quickly in a pair environment, he said.
Fellow panel member Jason Tice, director of Agile Coaching and Training Practice at Asynchrony, agreed that coaching is key. "Acknowledge that pairing is something that needs to be coached, Tice said. "Agile is a social process, it is not a technical process. And some developers are of the minds that they don't like to communicate that much."
Tice said he has coached teams to overcome such challenges, but it's sometimes tough to do. He emphasized that team members need to be accepting and accommodating of each other, adding that he coaches teams to talk about such issues out in the open and discuss how they can make the process comfortable for everyone.
"Sometimes you have people that have hygiene issues," Tice said. "They have physical space issues. They don't like someone being right next to them. They might have some issues that they're not confident in the code base and they're afraid someone's going to point the finger at them and say they don't have the technical skills to be on the team."
Again, the team leader needs to explain that pair programming is what they're going to be doing in order to write better-quality software, and if there are issues, the team should talk about it and figure out how to be successful, he said.
Matt Philip, the third member of the webcast panel, agreed that coaching is key, but warned that encouraging developers to try the practice is better than forcing it on them, if possible.
"Any time you kind of impose practices or impose a process, it gives people a way out. They don't have to own the decision for themselves," said Philip, the learning and development architect at ThoughtWorks Inc. Also, he said, it's best to find developers whose personalities better suit pair programming, if possible. At ThoughtWorks, he said, recruiters try to make sure candidates are comfortable with working alongside people and pairing up with others.
The IBM-sponsored webcast is available for replay for those who want to learn more about Agile, including how to sell it to management, essential practices to follow, how to start learning about the methodology, how to make it work with distributed teams in different countries and time zones, how to pronounce Kanban, and much more.
Posted by David Ramel on May 27, 2014