I’ve been doing more pairing lately. Much more. But, more specifically pair-coaching.
I’ve been pairing in my conference workshops and talks, quite a bit, with Mary Thorn on theagilequality 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. Now, I’m learning the value of having reviewers and editors. Second opinions matter. A second set of eyes matter. 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 writingthe book and her stories complimented my own experiences to give readers two sides to many coins.
Pair-Coaching in Agile Coaching
But I digress.The pairing I wanted to share in this article is around agile coaching. Not too long ago, a colleague of mine (Shaun Bradshaw) and I had the opportunity to work together on anagile transformationengagement. As most of these do, it had an initial training component and a team-by-team coaching component to it.
The idea was not just to get 10+ teams up and running, butto achieve some cross-team consistency in tactics and practices.
We quoted the work so Shaun and I would pair-coach periodically. There were 2-3 key trips/events where we visited the client together. Part of the reason for not embedding with the client were:
First, it’s not our primary coaching model. We prefer a part-time, at the iteration-endpoints model for our coaching.
We feel that embedding often slows the client learning down, as they can become too dependent on the coaches.
We want each of our clients to receive the best (most experienced) coaches possible and this model caters to that.
Essentially the model gives the clientspacefor execution, experimentation, and learning.Which enhances the impact of our next trip, as there are usually many questions and coaching opportunities. But they’re based on client ownership and real-time experience.
Some Resistance to Pair-Coaching
We noticed that it wasn’t easy to sell pair-coaching. The primary resistance factor is pure cost. That includes coaching and travel costs. But there were more subtle factors as well. For example, an undertone of – why can’t just one coach do all of this? Perhaps implying that our individual coaches weren’t skilled enough to handle all of the client’s needs.
It reminded me of the resistance I heard in the early days of pair-programming. Many couldn’t get beyond the simple economics to look to the intangible (but real) benefits of pairing, which included quality benefits, risk mitigation benefits, and execution benefits.
The reality is that even the best of coaches have blind spots. They can often miss important real-time aspects during their coaching. Having two sets of eyes working together can cover those blind spots. Making each of the coaches that much more effective.
Those same benefits need to be emphasized in pair-coaching to overcome the resistance.
And yes, the context matters.Pair-coaching makes more sense in instances where you’re coaching organizationally across many teams. Or are coaching up and down the organization.
It's Not Just the Teams
The other thing Shaun and I discovered, throughout our pair-coaching experience, is that we weren’t always coaching at the same level. What I mean by that is yes, we paired on the engagement, but we often split up for individual coaching. Let me give you a day-in-the-life example:
First thing in the morning we pulled three teams together to discuss backlog refinement practices. We’d both noticed that these teams, and their product owners were struggling with it. So, we ran an ad-hoc class focused on story refinement.
Next, we split up and attended individual team backlog refinement sessions. This allowed us more breadth of coverage and to show by example.
Right afterwards, we compared notes. Were there any common patterns? Were the individual product owners skilled enough. It turned out that a small subset of the product owners were really struggling. Shaun then continued working with the teams, while I pulled away to focus individually on product owners.
At lunch, we compared notes. Not only about the teams, but around what were we seeing at the organizational level. Each day we discovered aspects of the culture – both team and leadership. As our awareness changed, our strategies changed as well.
In the afternoon, I spent some time working with individual managers regarding their roles. Talking about how their behavior and approaches needed to shift a bit in an agile environment. Part of this was coaching, but another part was establishing a sense of trusted partner.
Shaun continued to focus on the teams. On this particular day, the focus was on architecture and how it “fit” into backlogs and team execution. So, Shaun spent a great deal of time with team leads and architects.
We wrapped up our day with a retrospective, discussing what we’d observed and experienced throughout the day. Then, we discussed strategy adjustments we could/would make for the next day’s coaching activities.
As you can see, our pair-coaching stance and our focus (the lens) changed in real-time throughout the day. That would have been really hard with a singular coach. Particularly given the normalblind spots.
And I can’t emphasize enough how powerful it was to have a “sounding board” right there in-the-trenches with you can be.
Changing Your Lens
I want to underscore this aspect of changing focus. Pair-coaching truly facilitates your ability to focus across various aspects of an agile transformation. What we did as coaches is ensure we were attentive to all 3-levels of the effort:
Directly involved managers – managing agile team members
Surrogates – for example: project managers, release managers
Activity – for example: metrics, tooling, organizational structure, HR
3. Leadership-based coaching
Direct leaders (technology, development, quality, product)
Indirect leaders (cross-functional leaders)
Stakeholders (direct stakeholders in the agile effort, could be clients)
And we pivotedacross all of these in real-time as conditions changed on the ground. It was incredibly powerful and positively impacted the client.
Adaptive Pair-Coaching Strategy
Each day as we prepared for our coaching, we would come up with an overall strategy for the day. It was based on:
Our original coaching contract – schedule and strategy.
Our learnings from the previous day.
Adjustments in the client team coaching opportunities.
Adjustmentsbased on our skills and client context.
Our focus became one of opportunity – coaching – outcome, as we progressed through the engagement.
One Voice
It’s really important to have ONE VOICE in your coaching. What I mean by that is, by and large, all of the coaches are referencing the same techniques, approaches, and making similar recommendations for the organizational context. There is an overarching consistency to the coaching stances, experience, and skills.
No, I’m not looking for the pairs to become automatons or clones of one another. That certainly wouldn’t be helpful. But at the same time, you can’t have one coach providing some tactical advice one day and another coach providing the diametrically opposite advice the next. There needs to be some philosophical alignment amongst the coaches.
So, the pairingalso helps to align the coaches (and the coaching) toward a 1-voice perspective so the client doesn’t get confusing or conflicting advice.
Wrapping Up
As I mentioned in the beginning, I’m trying to do more pairing in all of my activity going forward.In the end, I find my work is of higher quality, the impact is greater, and my “fun factor” is through the roof.
All of which creates better outcomes and results.
But at the same time, I still have to fight thru the resistance to pairing. It’s not simply client or cost resistance. I get a fair amount of resistance to pairing with folks personally.
I know, I know, stop with the jokes in your head.
A complimentary article to this one is the Agile42 posthere.
