One of the stranger things I noticed about pair programming was that I felt I was more efficient working with a pair than working on task alone. Mostly I felt it was because not only did I have someone to help out when I got slowed down, but interruptions had a bigger impact as there was someone sitting next to me, waiting for the interruption to "go away".
I know it's a shocker, but interruptions can have a huge impact on productivity, as we can't multitask, and too much email slows us down and stresses us out. In addition to some basic pairing etiquette rules, here are some general pairing tips to help improve your pairing productivity:
- Close email (both webmail AND Outlook)
- Close any RSS readers/aggregators
- Close any browser windows irrelevant to current task (i.e., that eBay item you're sniping)
- Set any IM clients to "Away" or with a message of "Pairing"
- Set your phone to "vibrate"
By forcing ourselves to minimize distractions, we also had to set aside parts of the day to deal with the distractions. It wasn't that we ignored emails and such, it's that we would only allow ourselves to address those distractions outside of pairing sessions. This lets us get closer to the 5-6 ideal engineering hours per day that we used for capacity calculations.
.png)
2 comments:
Now try convincing management how efficient you are becoming. I am playing devils advocate here. My team practices pair programming as well but I am always getting slammed when we get a new VP or someone to that degree start to inquire.
Honestly, expectations are so low in waterfall environments, the business is distracted with early and often delivery to care about the internal "how". I've only needed to justify to dev managers in the past, and the results have usually spoken for themselves.
It was hard to build trust to truly achieve "self-organizing" teams. But once we explained that if they trusted us enough to develop business-critical software, they should trust us to decide how.
Post a Comment