Switching pair-programming partners
How often should you switch pair-programming partners?Regularly switching partners supports the collective ownership of shared code and helps propagate knowledge and understanding throughout the team. However, switching doesn't come for free. Each time you switch partners, the flow is broken and it takes about 15 minutes to enter that flow again, plus any familiarisation time to bring your new partner up to speed with the current development thread.
I've seen two other factors come into play. The developers' level of experience and their level of familiarity with all the user stories planned in the iteration. If iteration planning is a team effort, which it should be, then the second factor is just about getting updated on the latest coding on a user story. With less experienced developers, it may take longer to re-enter flow because they require more time to get up to speed on the new user story. However, having less experienced developers switch often can be an effective learning experience providing the wasted time re-entering flow can be afforded. As a rule, less experienced developers should be paired with more experienced developers.
Here are 3 strategies that I've used for switching pair-programming partners, in order of preference:
- Switch partners at recurring, natural breaks in the day (and not necessarily when developers come up for air). The flow will be broken at these times anyway. User story owners select new partners immediately following the stand-up meeting in the morning and first thing after lunch.
- Switch partners every 2 hours, but realise that in an 8-hour day approximately 1 hour per pair is wasted on re-entering flow following each switch.
- Over time, I like to progressively split user stories so by the time they are planned into an iteration they take between 1 and 2 days to complete. Given a smaller user story, it's feasible for a pair to stay together for the duration of its development. In this scenario, the familiarity with the details of the user story, which comes about through working on the user story, is not shared beyond the owning pair. However, the other team members should at least be familiar with the desired functionality in the user story from the iteration planning meeting. And through the stand-up meetings and osmotic communication they should also be aware of changes that emerged from collaboration with the customer during development. Providing the code has a simple design, is well factored, communicative and self-documenting, has a high unit-test coverage and comes with a comprehensive set of acceptance tests (see FIT), pairing until the user story is complete has a negligible impact on the team's collective ownership.
Tags: agile, extreme programming, pair programming
posted by Simon Baker @ permalink
blinklist :
del.icio.us :
digg :
furl :
simpy :
spurl :
reddit
3 Comments:
I saw a talk at Agile2005 called "Promiscuous Pairing and Beginner's Mind: Embrace Inexperience." Here is a link to a paper and the powerpoint slides from the Agile2005 website. It was one of the more interesting talks that I attended. Just some food for thought.
Thanks Wilkes for your comments and the references to Arlo Belshee's Promiscuous Pairing. When I first started using extreme programming, I was working in an experienced team and we were swapping pair-programming partners every couple of hours. The velocity was around its highest when this was done, which correlates with the experimental evidence Arlo has produced.
On less experienced teams I've worked with I've not been able to reproduce this yet.
Most developers are very sensitive to pair-programming, a lot are resistant, most are curious but hesitant. I think if I introduced promiscuous pairing straight away it would possibly do more damage than good. Consequently, I like the switching at mid-day because it feels natural. If teams are resistant to pairing I ask them to work on user stories together. Based on my early experience (and Arlo's experiment) I think it's good to have teams try to ramp up to promiscuous pairing. How steep the ramp is depends on how quickly the developers become more confident when pairing and how quickly they start to feel comfortable working with a partner.
Here's a podcast of Arlo Belshee at Agile 2005 talking about Promiscuous Pairing and the Least Qualified Impementer.
Post a Comment
Links to this post:
Create a Link
<< Home