Greetings all –
My team has been reporting success with pair programming, so I wanted to try it out myself. This week one of my reports and I paired up to do a bit of maintenance work where we’re moving some automated tests around and setting aside some to act as compatibility tests. So it wasn’t exactly pair “programming” in the strictest sense but it was still pairing on nontrivial technical work and so essentially the same.
We had two pairing sessions this week, and then we’ll have another today to hopefully wrap the work item up.
I’m happy to report that it has gone well, much better than I expected. My experiences matched those which my team and others in the industry have reported:
After having done pairing on this task, I now find it frightening to imagine any critical coding task being done alone by somebody.
I still haven’t figured out a clean way to schedule pairing (in the sense of accounting for it in the sprint backlog). We are finding that velocity is a superior way to predictably schedule sprint capacity (as opposed to top-down scheduling by “person days”), which frees you from trying to do wacky mathematical translations from individual person day costings into pair costings. But I still to wrap my head around the best way to explain the cost impact to management types.
My advice: try out pair programming – it really is a great practice. I feel about pair programming the same way I did after doing TDD the first time: for tasks where it makes sense, I wouldn’t want to go back to doing it “the old way”.
Over & out!
Chris