Pair programming and extreme programming methods involve team members collaborating on the same programming activity They are at one workstation. A “driver” creates the code; a “watcher” reviews each line of code as it is written. Partners often switch roles. Along the way, they collaborate, and give each other feedback as they code.
Having two people pair on any kind of work has a number of advantages. Have you ever had to work with someone on a project? Is there anything else we need to discuss about pairing or working well together? It is critical to know how to work together on a piece of work.
This is the Pair Protocol. This is a guideline that describes how two (or more) people should work together to maximise alignment and productivity. Two people must cooperate in order to succeed.
The groundwork
You need work, a team, and a mentality conducive to teamwork. The work ahead is clearer after the piece of work has been refined. This is what you’ll be pairing with. You require people with the will to join forces, knowledge of the environment, and the intent to collaborate. When teaming, it is important to establish a mentality of “we” and “us” over “I” and “me”. Pair programming is one of a use case of pairing.
Mating / Pairing
First, two people volunteer to work together to complete the task. Ready, willing, and able, each person is. They can self-organize around their work (e.g., to have the option to volunteer for the work and have the ownership to determine how to do the work).
Collaboration
Before beginning work, one should align on how the pair will work together. they will briefly meet to re-re-familiarize themselves with the work, and then they will talk about how they will approach the work (e.g., through task decomposition).
This entails an agreement and commitment about who will do what, how they will do it, and when they will do it. There may be occasions where the pair works together. Discuss how this will be done (e.g., working session, etc.). This goes beyond programming and says, “pair programming.”
Taking input
Capture the important conversions and decisions that occur during a sprint, pairing, or time period as you go. There may be “discussion” functionality that allows the pair to remember the discussion.
Tapping into data
You should establish the best method to notify each other of when a task is complete and what kinds of feedback loops you’ll use with each other and with those outside the pair in order to improve the work. It is essential that feedback loops are identified and used, and how feedback is applied back into the work.
this work definition may record this information (e.g., user storey details, etc.). Activating this feature helps to keep each other aligned with the progress. Above and beyond what is traditionally included in ‘pair programming’.
Result sharing
Acceptance criteria is defined by the working pair, i.e. the navigator and the driver. When the work is complete, a way must be found to agree and meet the acceptance criteria. Sharing results prior to the team should be anticipated here.
It is critical to know where the outcomes of the work can be shared and discussed. Agile and Scrum: Scrum reviews and demos provide the venue for sharing work and getting additional feedback. The pair should also discuss who will demonstrate the work, collaborate on what type of feedback they are seeking during the demo, and agree on whether they’ve met the acceptance criteria of the work (if any).
