Pairing is not a new concept. The Agile community found much success with pairing two developers using the XP technique of pair programming. Recognizing that Agile pair programming provided great opportunities for both parties to learn and collaborate, this idea has expanded to pairing people in a variety of circumstances.
At Agile2016 in Atlanta, Victor Bonacci and Brett Palmer delivered an interactive session entitled "Domino Game: Pair-Coaching to Increase Self-Efficacy." In the session, they provided the audience with different patterns that can be used for pair coaching and discussed which style might be most effective in different contexts.
Who can pair coach?
The short answer to the question, "Who can pair coach?" is "Anyone!" Through the extreme programming practice of Agile, pair programming pairs two developers of an equal skill level. Pairing can be used in a variety of situations with any type of role. You may want to pair two people who have different skill levels for mentoring or training purposes or pair two people with different roles so that there's more cross-training and stronger collaboration.
Pairing works well in almost any situation because it provides a second set of eyes, ears and a second perspective. Each person in a pair will have the benefit of some kind of support. Both parties, regardless of role or skill level, typically learn and benefit from witnessing a differing style or viewpoint, and they enjoy the benefits associated with pairing. Self-efficacy, defined as one's belief in one's ability to succeed, is certainly improved when you have a partner that has got your back. And pairing often leads to strengthened connections, bonding and friendships.
Patterns of pair coaching
Like almost anything "Agile," there isn't a "one-size-fits-all" approach for how to properly pair coach. Rather, there are patterns that can be used depending on the context of the situation. Victor Bonacci has compiled a list of pair coaching patterns that he's outlined on his website www.agilecoffee.com.
Without covering all of the various patterns, let's take a look at some of the most common.
In this model, the "trainer" may be a traditional trainer or a facilitator of some sort. The "observer" is in the background and can help with logistics, to answer questions and is basically available to help support the trainer. If the "observer" is more experienced than the trainer, perhaps he will offer feedback to the trainer on how the trainer might be able to improve. If the observer is not as experienced as the trainer, perhaps he can use the observation as an opportunity to learn how to train.
This pattern is the one used in traditional Agile pair programming and is used only between the pair of people working together, rather than with a big group as described with the trainer/observer pattern. As with Agile pair programming, having that second set of eyes will provide higher quality.
When asked which pattern was his favorite, Palmer answered the driver/navigator pattern. "It has a lot of practical, everyday applications, especially as an agile coach. For example, next week I'm coaching a team in how to use Rally (CA Agile Central) and I'm going to be teaching the scrum master how to set up and configure the tool for each of those new users on his team. He'll actually be the one at the computer typing and I'll be explaining to him verbally where to go and where to click."
In this way, Palmer is having the scrum master use the tool so that he gets the hands-on experience, yet Palmer is still guiding him as he learns.
Sometimes labeled as good cop/bad cop, this pattern has the two partners offering up alternative viewpoints. This may be effective as a technique to get a team to open up about how they really feel. One partner may play the "devil's advocate" in order to make it safe for there to be constructive dialog between team members.
In this type of pairing, the "senpai" is the mentor or senior of the two and is there to guide the "kohai." This is popular with employee integration because it can help a new member learn the ropes.
In this pattern, both partners are learning together. By pairing with someone to learn, you're able to provide feedback to one another and, again, provide help and support to each other.
Additional patterns were identified on the pattern handout provided by Bonacci and Palmer and, understandably, others will evolve. I've seen a couple of different patterns emerge in my work with distributed teams with remote pairs. For example, if those who are remote have a "buddy" at meetings where most people are colocated, the pair can be IM'ing, ensuring the remote person can hear and can be made aware of what's going on in the room.
Just like with Agile pair programming, there is no one right way to pair, and one pattern will not work in every situation. However, as Bonacci and Palmer demonstrate in their interactive presentation, pairing provides an effective way to communicate, collaborate and support one another in a variety of situations. Whatever your role is on your team, think about how you might be able to pair with others at times to learn, teach, connect and support one another.
Is it time for a new Agile manifesto?
How to decide among Lean, Agile and DevOps