Pairing

Two people work on the same task together, continuously reviewing
each other's work and providing feedback

What is Pair Programming?

Pair programming is a dialogue between two people trying to simultaneously progam (and analyze and design and test)
and understand together how to program better. It is a conversation at many levels, assisted by and focused on a computer-- Kent Beck in Extreme Programming Explained

XP Needs Pair Programming

We believe pair programming is an integral part of XP, and it
is dangerous to do XP without doing pair programming. One primary
reason is that the pairs keep each other honest. XP is a minimalist
approach, so it is essential that many of the practices actually get done.
-- Laurie Williams & Robert Kessler in Pair Programming Illuminated

The bulk of the design on XP projects occurs during pairing.
Two people work on the same task at the same time, continuously
reviewing each other's work. Whenever pairing is dropped from XP,
design quality takes a plunge, while the defect count rises
significantly.

Two people can pair to write stories, storytests, code or
documents. It is common to pair across sub-teams pairing during
integration and smoke testing, or when implementing stories that touch
different subsystems.

7 Risks of Solo Programming

Tunnel Vision (a.k.a. Frog in a Well)

Fatigue

Higher defects

Less knowledge transfer

More distractions

Less refactoring

Weaker problem solving

Cross-Pollination

It is important to cross-pollinate across sub-teams from time to time,
so the team has a working idea of the entire system, beyond individual
specializations. It is also important to note that there are some
pairing combinations may not make business sense - like pairing a
mainframe resource with a java resource on a java/mainframe programming
task. However, such pairings do make sense when timeboxed in the
context of short tasks that involve talking to different subsystems.