Tim and Tim discuss tools and techniques and observations for remotely pair-programming. Various remote desktop-sharing applications and services are discussed, dissed, and recommended along with pointers and practices for logistics. Learn the downside of distant partners. How do you have a flash architecture meeting? How do you collaborate with the team? When do you take breaks? Is it really just like being there, without the smells?

I think Pair Programming is vital to the success of a programming team, but every time I join a new team I seem to find I’m in a minority of people who feel that way, let alone have any experience of actually doing it.

Three basic tools - pen, paper and a kitchen timer - will give you Agile values like…

• Constant feedback about your working habits
• Dedicated decision points to respond to change
• Opportunities on a day to day basis to improve your personal process
• A sustainable pace even when the deadlines are getting closer
• Improved quantitative and qualitative estimates
• Strategy for coping with interruptions and task switching
• Ability to regulate complexity

Most sessions show us how to do various agile practices right. What is sorely lacking is the opportunity to learn how to do the practices wrong. How can we be expected to bring agile into an organization successfully without mastery of that key skill?

Pairing isn’t controversial, done effectively it: * reduces defects (by up to 86%, according to the 2000 University of Utah study), * improves productivity (up to three-fold, according to the 1975 US Army study)

However, learning by doing wrong is actually an effective learning technique, and that’s what you’ll see here.