In 2017 I shared an article on Pair-Coaching. In it, I shared some ideas & experiences around pair-coaching.
Now in 2020, I’ve had a bit more experience doing it. Not as much as I’d like, but more experience.
This article is inspired by an Agile Moose Herd conversation we had around the idea of – what would an apprenticeship program look like for coaching? And the notion of pair-coaching came up as a part of that activity. As would doing Dojo-based coaching simulations.
Questions from the Herd…
Do you have to work in pairs all the time?
Of course not. I think that’s probably the equivalent of mandatory pair-programming for every line of code. It simply doesn’t make sense.
In fact, there are some days when I’m “pair-coaching” where I/we don’t pair at all from a client coaching perspective. That being said, we do pair to prepare for coaching, debrief coaching, and strategize for upcoming coaching.
What are some of the “dynamics” of pairing?
There are a couple of things that come to my mind…
First, who will take the “lead coaching role” needs to be established before the pair engages in each direct coaching situation. The lead then does exactly that…lead or drive. They are the coaching voice for the coaching session.
I’ve been doing more pairing lately. Much more.
I’ve been trying it in my conference workshops and talks. Pairing with Mary Thorn quite a bit on the agile quality and testing side of things. I’m also pairing with Josh Anderson on our Meta-cast and I’ve done a few presentations with him. Very enjoyable.
I’ve also been pairing more in my writing. For years, I’ve been a lone wolf writer. Nobody but myself saw my writing before it entered the light of day. But now, I’m learning the value of having reviewers and editors. Second opinions matter. A second set of eyes matter. And having a partner in your endeavors can be quite a bit of fun.
An example of this is Mary Thorn being my “Chief Story Teller” in my 3-Pillars book. We had a blast writing the book and her stories complimented my own experiences to give readers two sides to many coins.
I think it was George Dinwiddie that first coined the term “3 Amigos” in agile development around 2009. The analogy was akin to the movie from the mid 90’s by the same name. The Amigos in the agile sense are functional roles:
- Developer(s);
- Tester(s);
- and the Business Analyst or the Product Owner.
It could literally mean more than three as well. The point was, balanced collaboration in agile teams across these roles. George was alluding to these roles from an Acceptance Test Driven Development (ATDD) perspective. He wanted these three constituencies to be heavily collaborative (conversations) around the Acceptance Tests or Acceptance Criteria for each user story.
