Pairing isn't just for programming, it can be advantageous to have two people pairing on any type of work. Have you ever had to pair up with someone on a piece of work? Have you ever launched into the work only to realize that you haven't discussed how to pair up or realized that you aren’t really working well together? There are dozens of different ways to work as a pair so it is important to have protocol on how to work together through a piece of work. I call this the Pair Protocol. This is a guideline on how two (or more) people engage together in a piece of work to have the maximum alignment and productivity. The objective is to get two people to work as one.
Setting the stage
You need a piece of work, team of people, and the right pairing mindset. The piece of work can be a feature, a user story, a requirement, an increment, or similar that has been refined so the work ahead is clear. This forms the basis for what you pair around. You need people who are coming together for a common purpose, know the context around the work, and are willing to work together. You also need a mindset of “we” and “us” over “I” and “me” as pairing implies that all collaborators of the work in harmony and get the credit together.
You need a piece of work, team of people, and the right pairing mindset. The piece of work can be a feature, a user story, a requirement, an increment, or similar that has been refined so the work ahead is clear. This forms the basis for what you pair around. You need people who are coming together for a common purpose, know the context around the work, and are willing to work together. You also need a mindset of “we” and “us” over “I” and “me” as pairing implies that all collaborators of the work in harmony and get the credit together.
Pairing up
The first step is for two people to volunteer to do the work together. This implies each person is ready, willing, and able to do the work. It also means they can self-organize around the work (e.g., to have the option to volunteer for the work and have the ownership to determine how to do the work). This typically occurs in a session where the work has been discussed and it's time for people to volunteer to do the work. This could be in a form of a planning session (e.g., for Scrum it would be Sprint Planning, for Kanban it would be the Queue Replenishment, and in traditional approaches, it would be a project planning session. The outcome is that two people (aka, the pair) have willingly volunteered for a piece of work.
The first step is for two people to volunteer to do the work together. This implies each person is ready, willing, and able to do the work. It also means they can self-organize around the work (e.g., to have the option to volunteer for the work and have the ownership to determine how to do the work). This typically occurs in a session where the work has been discussed and it's time for people to volunteer to do the work. This could be in a form of a planning session (e.g., for Scrum it would be Sprint Planning, for Kanban it would be the Queue Replenishment, and in traditional approaches, it would be a project planning session. The outcome is that two people (aka, the pair) have willingly volunteered for a piece of work.
Working together
Once the pair has been created and the planning is done, the first step of beginning the work is aligning on how the pair will work together. The pair will briefly meet to re-familiarize themselves of the work (e.g., discuss the “why”, acceptance criteria, etc.) and then discuss how they will navigate through the piece of work (e.g., through task decomposition). This includes an agreement and commitment on who will do which tasks, how they will do the tasks, and when they will do the tasks. As this is pairing, there may be tasks where the pair works together. If so, discuss and gain agreement on how this will occur (e.g., working session, etc.).
Once the pair has been created and the planning is done, the first step of beginning the work is aligning on how the pair will work together. The pair will briefly meet to re-familiarize themselves of the work (e.g., discuss the “why”, acceptance criteria, etc.) and then discuss how they will navigate through the piece of work (e.g., through task decomposition). This includes an agreement and commitment on who will do which tasks, how they will do the tasks, and when they will do the tasks. As this is pairing, there may be tasks where the pair works together. If so, discuss and gain agreement on how this will occur (e.g., working session, etc.).
Capturing Discussion
As you pair through the sprint,
increment, or time period, you should capture important conversions and
decisions where the work definition (e.g., user story, etc.) is recorded. There
may be ‘discussion’ functionality that can be used that allows the pair to remind
themselves of the discussion.
Incorporating Feedback
It is important to agree on how you will notify each other when a task is complete and what types of feedback loops you will use with each other and with those outside the pair to gain feedback to ensure the work is moving in the direction of value. There should be an agreement on what feedback loops will be used (e.g., review sessions, etc.) and how will feedback be incorporated back into the work. This information can be recorded in the work definition (e.g., user story details, etc.). If the planning or backlog management tool has a “follow” feature, then activating this will help keep each other aligned with the progress.
It is important to agree on how you will notify each other when a task is complete and what types of feedback loops you will use with each other and with those outside the pair to gain feedback to ensure the work is moving in the direction of value. There should be an agreement on what feedback loops will be used (e.g., review sessions, etc.) and how will feedback be incorporated back into the work. This information can be recorded in the work definition (e.g., user story details, etc.). If the planning or backlog management tool has a “follow” feature, then activating this will help keep each other aligned with the progress.
Sharing Results
As the work comes to a conclusion, there
needs to be a way to agree that it is completed and meet the acceptance
criteria. This should occur prior to sharing the results with the greater team
or those outside the pair. Sharing results include identifying the venue where
the outcome of the work can be shared and discussed. If you are using Agile or
Scrum, the Sprint Review or demo can provide the venue for sharing the work and
gaining any additional feedback. The pair should also discuss who would demo
the work, collaborate on what type of feedback they are looking for during the demo,
then jointly agree on whether they’ve met the acceptance criteria of the work,
and what are the next steps (if any).
Combining our passion and determination to help our clients succeed, we enable you to infuse long-lasting business change and get the most from the Agile Transformations Company in Noida. Accelerate your agile evolution in rapid digitization with the latest digital technologies for Techsaga.
ReplyDelete
ReplyDeleteThis is really informative blog, I have to thank for your efforts. Waiting for more post like this.
Ethical Hacking Course in Chennai
Ethical Hacking Online Course
Ethical Hacking Course in Coimbatore