1. Don't dictate â€" discuss. Discuss the ideas of pairing and its pros and cons with your team rather then dictating rules to them. Pairing is an excellent opportunity for developers to learn from each other.
2. Decide how much pairing your team will do. Pairing is a very intense but satisfying way of working.
3. Don't simply start pairing eight hours of the day â€" your team will be burnt out. Start small â€" maybe an hour to two each day and see how it progresses, and increase as the team gains confidence.
4. Regular checkpoints. If you have decided to try it again make sure you provide formal settings for the team to provide feedback on how it's going.

Critical Success Factors

• Try it â€" if you don't try it, you'll never know.
• Time â€" give your team the time to try it and go step by step.
• Communicate â€" pairing can reveal some controversy â€" be sure to keep the lines of communication open.
• Pairphobia â€" you will encounter someone who simply refuses or does not want to pair. Typically there is something else driving this which you will need to address.
• Time for thinking - Developers need time to think, and work out ideas â€" be sure to give people space to do other things.

Overall what we're saying here is try it â€" first try the test-code-refactor cycle, and once you get that working, try some pair programming. Immediately you should begin to see an increase in quality and a higher level of communication amongst the team.

What we didn't cover is simple, incremental design. Agile favours simple incremental, evolved designs rather then large designs created before any coding. Many take this as Agile favours no design â€" which it does not, but rather says do only as much as is needed.

In part two of this series we will look more closely at simple design, as well as the next set of practices that make up the development team practices.

References

1. Beck K with Andres C, Extreme Programming explained: embrace change 2nd ed., Pearson Education, 2005
2. Beck K, Test-driven development: by example, Pearson Education, 2003
3. Jeffries R, Anderson A, Hendrickson C, Extreme Programming installed, Addison-Wesley, 2001
4. Wake W, Extreme programming explored, Addison-Wesley, 2002
5. Meyer B, Object-oriented software construction 2nd ed., Prentice Hall, 1997
6. Fowler M, Refactoring: improving the design of existing code, Addison Wesley Longman, 1999
7. Williams L et.al., Strengthening the Case for Pair-Programming, University of Utah Dept. of Computer Sciences, 1999