Applying the Pair Protocol beyond Programming

-->

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.   

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.

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.).

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.     

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). 

Agile - Is it Real or is it Fake?

At the World Agility Forum in Lisbon Portugal on September 29, a panel of leading Agilists focused on “Shifting perspectives to know what is Real (agile)” The panel was made up of Chet Hendrickson, Steve Denning, Nigel Thurlow, and Mario Moreira.  We discussed “What is fake Agile? What is real Agile?”

What is real Agile?  It starts with an alignment to the Agile Values and Principles.  Without understanding and embracing the values and principles, whatever a company is doing is certainly something but can it really be considered real agile?

Agile is more than mechanically applying Agile processes. This I refer to as “doing Agile”. More important than choosing a particular process of Agile, is the art of learning how to live Agile values and principles, to transform Agile mechanics into Agile mindset. This is what I call “being Agile.” 

Steve shared that fake Agile is really a reference to “Agile in name only”.  Since many companies want the badge, he indicated that to understand if companies are Agile, you need to look beyond what they are saying and look at what they are doing.

Nigel discussed how companies feel the need to get on the Agile bandwagon and do Agile as it is the trend.  He stressed the importance of understanding the benefits that Agile can bring and focusing on this instead of Agile itself.

Chet shared that there may be something much worse than fake Agile and that is “dark Agile”.  This is using Agile as pressure to get more work done or impose Agile on a team and not remove any of the constraints leading to numerous anti-patterns. 

Mario talked about a concept akin to fake Agile which I call “FrAgile”. This is when Agile is so minutely applied with little focus on the Agile Values and Principles that it quickly becomes brittle, lacks vigor, and shatters once there is tension applied, leading to a regression to old ways of working.

It was a healthy and collaborative discussion leading to a clear awareness of how fake Agile is damaging the good name of Agile.  Instead, it is time to bring pointed awareness of what is and isn’t agile and advocate for “being Agile” and the outcomes it can bring.

For more on Fake Agile, consider reading:

• Understanding Fake Agile by Steve Denning  
• You may be FrAgile if… by Mario Moreira