Pair Programming

2. Driver/Navigator Facilitation ⚡ (Power Mode)

Steps:

1. Driver responsibilities:
   • Write code, run tests, navigate the editor.
   • Think aloud — narrate what you're doing and why.
   • Ask questions when navigator's direction is unclear.
2. Navigator responsibilities:
   • Focus on strategy, architecture, and upcoming steps.
   • Catch typos, logic errors, and naming issues in real time.
   • Keep a running list of TODOs and tangents to revisit later.
3. Rotate roles at the agreed interval or at natural breakpoints (test green, commit point).
4. Both participants commit under shared authorship: Co-authored-by: Name <email>.

3. Mob Programming Coordination ⚡ (Power Mode)

Steps:

1. Assign roles:
   • Driver — Types only what the navigator dictates.
   • Navigator — Directs the driver; rotates every round.
   • Mob — Contributes ideas to the navigator, not the driver directly.
2. Rotation: Navigator → Driver → Mob; new Navigator from Mob.
3. Rotation interval: 10–15 minutes for mobs of 3–5 people.
4. Use a visible timer (Mobster, Mob Timer app).
5. Designate a facilitator to manage flow, breaks, and conflicts.

4. Knowledge Transfer Debrief 🌿 (Eco Mode)

Steps:

1. At session end, spend 5–10 minutes on debrief:
   • What did we accomplish?
   • What did each person learn?
   • What surprised us or was harder than expected?
2. Capture key decisions and rationale in a commit message or doc.
3. Log any follow-up tasks or tech debt discovered during the session.
4. Rate session effectiveness (1–5) and note improvement ideas for next time.

Inputs

Outputs

Edge Cases

• Significant skill gap between participants — Use strong-style pairing; senior navigates at a level the junior driver can execute.
• Remote pair with high latency — Prefer asynchronous ping-pong (push commits alternately) over real-time screen sharing.
• Participant dominates the session — Facilitator enforces strict role boundaries; driver only types, navigator only directs.
• Task turns out to be trivial — Pivot to a related learning exercise or review adjacent code together.

Scope

In Scope

• Structuring pair and mob programming sessions (roles, rotations, timeboxing)
• Facilitating driver/navigator, ping-pong, and strong-style pairing workflows
• Managing remote pairing tool setup (Live Share, Tuple, screen sharing)
• Knowledge transfer practices and session debriefs
• Co-authorship attribution in commits
• Rotation scheduling and timer management for mob sessions
• Session retrospectives and effectiveness tracking
• Onboarding acceleration through guided pairing with experienced team members

Out of Scope

• Code review and defect classification (handled by code-review)
• Git workflow and branching strategy (handled by git-workflow)
• Task selection and sprint planning (handled by task-decomposition)
• IDE/editor configuration beyond collaboration plugins
• Performance evaluation of individual contributors
• Meeting scheduling and calendar management

Guardrails

• Never allow a single participant to hold the driver role for more than two consecutive rotation intervals.
• Always attribute commits with Co-authored-by trailers for all active participants.
• Sessions must not exceed 90 minutes without a break; enforce a 10-minute break after each 60-minute block.
• The navigator must not take over the keyboard — communicate intent verbally or via chat.
• Do not use pair programming sessions for performance evaluation or comparison of participants.
• Ensure all participants have equal environment access (repo, CI, docs) before the session starts.
• Tangential discussions exceeding 5 minutes must be parked in a TODO list and revisited after the session.

Ask-When-Ambiguous

Triggers

• Participants have not paired before and preferred style is unknown
• Skill gap between participants is significant and unclear how to bridge
• Session goal is vague (e.g., "work on the backend")
• Remote tooling preferences are not established
• Session involves more than 2 people but mob programming was not explicitly requested

Question Templates

1. "What specific task or problem should this pairing session focus on?"
2. "What is the experience level of each participant with this codebase or technology?"
3. "Do you prefer driver/navigator, ping-pong (TDD), or strong-style pairing?"
4. "For remote sessions, which collaboration tool should we use — VS Code Live Share, Tuple, or screen sharing?"
5. "How long should the session run, and what rotation interval works best for the group?"

Decision Criteria

Success Criteria

• Session has a clearly defined goal before starting
• Roles (driver/navigator) are assigned and rotated at agreed intervals
• All participants actively contribute during the session
• Co-authorship is attributed on all commits made during the session
• Session produces at least one commit or documented decision
• Debrief captures learnings, follow-ups, and session effectiveness rating
• No single participant dominated the keyboard for the entire session
• Knowledge transfer occurred — each participant can articulate something they learned

Failure Modes

Audit Log

• [timestamp] session-started: Pair session with <participants> — style: <pairing-style>, goal: <task-description>
• [timestamp] role-rotated: Driver switched from <previous-driver> to <new-driver> at <interval> minute mark
• [timestamp] commit-made: Committed <sha-short> with co-authors <co-author-list>
• [timestamp] tangent-parked: Deferred discussion on <topic> to follow-up task
• [timestamp] break-taken: 10-minute break after <elapsed> minutes of active pairing
• [timestamp] session-completed: Duration <total-minutes> min, commits: <commit-count>, effectiveness: <rating>/5
• [timestamp] debrief-logged: Learnings: <learning-count>, follow-ups: <followup-count>