Whenever I heard the term “pairing”, I used to think of wine and food. The process of combining certain wines with certain foods so that the unique texture, flavours and chemical compounds of one enhance the other to create a climatic dining experience. I am by no means, a wine connoisseur or a sommelier. The limits of my wine and food pairing don’t go beyond the basic red wine with red meat and white wine with poultry or seafood. Beer and pizza complete each other as well! However, the art of pairing is so much more than that. I remember watching a cooking show where the Canadian celebrity chef, Susur Lee, referred to combining different ingredients as a “marrying of flavours”. In fact, there’s another term, “food pairing”, that extends the wine pairing concept to combining different types of food that match from a nutritional and digestive perspective. Peanut butter and jam on toast comes to mind 😂.
Beyond food and drink, another form of pairing that comes to mind is the “chemistry” that’s created in sports between two or more players. In ice hockey, I think of current dynamic duos like Matthews and Marner, McDavid and Draisaitl, Suzuki and Caufield, Marchand and Pastrnak. Anticipating each other’s moves and knowing where each other will be at any point in time to receive a pass for a one-timer or to tip a shot into the net. Each makes the other a greater combined threat to opposing teams.
In software development, a common use of pairing involves the XP practice of pair programming. Sharing a single computer with a single keyboard and mouse, two programmers take turns working on a single piece of code. This promotes a higher level of quality and learning than would solitary programming alone. More recently, this has evolved into mob programming that engages a raft of team members, and not just programmers.
In my early waterfall days as a programmer, before pair programming was conceived, I was confronted with a litany of software development practices meant to squeeze quality out of our code. Those practices felt episodic, one-dimensional and at times, draconian. Practices included:
- Development cookbooks
- Coding style guidelines
- Functional specification reviews
- Code walkthroughs or reviews
- Static code analyzers like Lint
- Quality Assurance audits of software development processes
Those practices often left me either puzzled without answers to my questions about the cookbook and guidelines or embarrassed, defensive or both during reviews of my artifacts and code.
Pair programming helps alleviate those concerns in a number of ways.
- The code becomes a co-creation of two people. With mutual support for each other when the code or its ideas are challenged.
- Two heads are better than one when it comes to asking and answering questions.
- It enables a natural, continuous flow of interactions.
- Interactions that lead to greater insights and learning.
- There’s less complacency and more accountability to each other for making the code better, safer and of higher quality.
How might these benefits of pairing be applied beyond programming?
I’ve had the good fortune of experiencing two ways to extend the benefits of pairing into Agile Coaching.
Personality Pairs
Opposites may attract when it comes to personal relationships but less so when it comes to professional relationships. With professional relationships, opposing views can be a challenge to work through. It’s more often better “the devil you know than the devil you don’t know” to effectively work with each other. There are a couple of ways to do this.
One way is using personality tests such as the Jungian based Blue, Red, Yellow and Green personality types, where,
- Blue = Introverted Thinker
- Red = Extroverted Thinker
- Yellow = Extraverted Feeler
- Green = Introverted Feeler
If you’re a solid yellow personality type dealing with a predominantly blue individual or group, you’ll understand why they’ll want to see the data behind your sunny smile.
Having problems pairing teams that need to work together? Try using a Myers-Briggs Type Indicator personality test (e.g. 16Personalities.com) to aggregate each team’s individual types into a predominant team type. Maybe you’ll find one team is predominately Introverts while the other is predominantly Extroverts. That could explain why one team always dominates the conversation while the other appears disinterested. Nothing a bout of silent writing can’t handle.
A second way is using performance and potential based assessments such as StrengthsFinder. A colleague of mine is a StrengthsFinder coach and facilitator. She uses a structured approach to analyze and gain insight into our 34 talent themes so that we know what each of us needs to perform at our best and how we can complement each other as a coaching pair in joint client engagements for the maximum benefit to our clients.
Coaching Pairs
Some of my fondest and most memorable Agile coaching moments have occurred as part of a coaching pair or tandem. In my experience, pair coaching has served a couple of purposes:
- To meet a level of Agile coaching that exceeds the capacity of a single Agile Coach.
- To share and impart skills and knowledge with internal Agile Coaches who will be sustaining the coaching relationship long after I have left.
For me, pair coaching has enabled me to continuously “sharpen my saw” and revitalize my coaching tools in general. A second pair of eyes when coaching, facilitating, teaching or mentoring clients has kept me honest and humble. Pair coaching not only facilitates learning for both coaches, it’s also a gateway to…
- Co-creation
- Enhanced vulnerability
- Mutual support & help
- Fresh perspectives
- Surprising breakthroughs
- Collective ownership
Just as pairing wine with food enhances the overall dining experience, pairing a couple of Agile enthusiasts can enhance the overall client experience.
Bon appétit!
nextchapterconsulting.ca 