Tag-team pairing is a casual, free-form arrangement in which the driver and navigator switch roles whenever either person has an idea, gets stuck, feels tired, or otherwise chooses to hand over control. Unlike ping-pong or Pomodoro pairing, it uses no fixed switching rule or time interval. section 11.2.2
The flexibility makes tag-team pairing useful when the pair needs to follow changing ideas or recover from obstacles. It works best as a deliberate team choice rather than an excuse for one person to dominate the session. section 11.2.2 section 11.2.3
Use tag-team pairing when:
- A navigator has a useful direction to pursue or a driver is stuck or tired. section 11.2.2
- The work benefits from two perspectives, such as critical systems, core libraries, complex problems, architecture design, refactors, or experimental solutions. section 11.2.3
- The team sets explicit boundaries, such as starting with 30-minute-to-one-hour sessions, because free-form switching does not prevent pairing fatigue. section 11.2.3
A legacy-system bug
While debugging a legacy system with deep dependency injection, inconsistent names, and few unit tests, a developer repeatedly asked a colleague with more historical context for help. Pair programming and code reviews then helped spread the reasoning behind the refactor, improving application health and making later bugs easier to find. section 11.2.2
Table 11.1 Pair programming pairing styles
|
Pair style
|
How it works
|
Pros
|
Cons
|
|---|---|---|---|
|
Driver-navigator
|
One driver: focuses on writing the actual code
One navigator: focuses on reviewing the code being written in real time
|
Most common; the pair has equal chances to contribute and review
|
Uneven personality matches might result in a single driver the entire session; the passive navigator might not review as effectively
|
|
Driving school
|
One navigator: focuses on giving tactical, direct, and detailed instructions to the driver
One driver: follows the navigator’s instructions
|
Can be useful if the pair has previously discussed a solution about to be implemented
|
Stronger personality might unintentionally perform this style when paired with a more timid developer
|
|
Pomodoro
|
One driver, one navigator (as in driver–navigator style)
Pair program in 25-min intervals; 20 min coding, 5 min break. Then switch roles
|
Equal participation time between the pair; naturally breaks down pairing sessions into manageable chunks
|
Constant switching might be hard for some developers; can be difficult for pairs with different skill levels
Timing might be an anxiety driver (“I only have 5 min left to finish this”)
|
|
Tour guide
|
One driver: focuses on explaining and implementing code
Multiple navigators: passively listen to driver
|
Useful for onboarding or when new implementation has to be shared with the greater team
|
Passive listeners can grow bored or “zone out” as they don’t get to participate in actual code writing
|
|
Ping-pong
|
One writes a test; developers switch; currently active developer writes code to pass the test. Writes the next test and then switches; cycle continues
|
Great with Test-Driven Development; useful for range of skill levels
|
Constant switching might be hard for some developers; can be difficult for pairs with different skill levels
|
|
Tag-team
|
One driver, one navigator (as in driver–navigator style); switch driver role as the pair sees fit
|
Casual, free-form; developers decide when to switch
|
If one favors more control or is more passive, switching may not occur as frequently
|
Compare tag-team pairing with driver-navigator, driving-school, and Pomodoro styles by how they assign roles, structure switching, and distribute participation. section 11.2.2
