AGILE IN ACTION

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:

1. 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.
2. 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.
3. 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 .