If you’re a basketball fan and know who Allen Iverson is, then you’ll probably remember his infamous rant about “practice”. While he can never be questioned for the effort he put forth in games, he didn’t have a fondness for practice.
Now that doesn’t have much to do with coaching. Yet, I like the reference.
In this article, I did want to explore the notion of practice related to becoming a better coach. Both a professional coach and an agile coach.
A Sidebar
Not that long ago, I had a young woman sit down with me at a coaching clinic at the Scrum Alliance Gathering. She was a Millennial looking for career advice and she was very direct.
Bob, I want to achieve your level of expertise in the agile coaching community and I want to do it in a year. Please tell me how to do that.
Sadly, I don’t think my answer helped her nor was it well received. It was simply that…you can’t. And I wasn’t speaking from a position of ego. But from the position that it’s taken me ~20 years to acquire whatever skills I have in my journey. And I didn’t think that can easily be encapsulated and subsumed overnight or within a year.
We were in my Agile Moose Herd coaching circle and the question came up about a coaching firm that had come into an organization and said something like…
We want to focus on the future and don’t really want to look backward. It’s all about what’s in front of us. So, everyone, please let’s talk about agile going forward and not about what did (or did not) work in the past.
And the question was—
Was that a fair way to enter an organization as a coach? Basically, to place history off-limits to the discussions?
This made me/us consider the idea of entering an organization (group, tribe, company, system) as a coach or change agent and explore the first few steps you should be taking upon entry?
Here I capture where the discussions landed on an—agile coaching entry strategy with a client embarking on an agile transformation—
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 don’t believe I’ve ever read any guidance around ENTERING a coach. Well, other than “plopping” (parachuting, dropping, etc.) them into a situation and telling them…
Go Coach!
And this is less about how the coach enters, but more about how the organization’s leaders explain things before the coaches engage.
For example, the following questions need to be answered and communicated before the coaches ever enter the engagement—
I saw the following post on LinkedIn from my colleague Maurice “Mo” Hagar –
"Fostering a new mind-set and creating a new culture is no easy feat."
https://www.strategy-business.com/article/Creating-an-agile-mind-set-at-PepsiCo?gko=20fae
Good read. I've done Agile coaching since 2005. Back then it was easy: stand up a Scrum team. Today we're doing business agility, at scale, across the enterprise, and that's not so easy. Because it's no longer about "Agile" and local optimization but about the "business"--mindset / culture and outcomes--as it should be.
There are two kinds of Agilists in the world: 1) those who talk mostly about Agile, and 2) those who talk mostly about the business. Don't mishear me; I'm all for all that "Agile" means. But the most important thing I've learned at IBM, my primary client for the past two years? "Show me results or I'll show you the door."
That sounds harsh but it's how the game of business is played—all professional sports, in fact. And many of us Agilists need to up our game. While we're talking Agile, all the execs hear is "blah blah blah." Because they speak one and only one language: $$$. If you can't go there go home.
You can view it and the replies here - https://www.linkedin.com/posts/mauricehagar_creating-an-agile-mind-set-at-pepsico-activity-6603998919653421056-1Clb
I have just a couple of responses to Maurice’s comment…
A while ago, I was talking to my colleague Mary Thorn about the notion of agile “playbooks”. Mary had been working with a client in NYC and had developed a playbook for their agile adoption and practices. From her perspective, developing these sorts of:
Guidelines
Rules
Methods
Standards
Guardrails
Were invaluable for helping a large organization effectively transforming with agile approaches.
During the development and deployment of the playbook, she asked me to share my playbook. And the very question caused me to pause.
I’ve been an agile coach for ~20 ears, so I certainly have the chops. But upon reflection, I realized that I’d never, ever developed a playbook for a client. And I sort of busted Mary’s chops a bit around the idea.
Why you might ask?
I was in one of my Moose Herd (virtual Lean Coffee, coaching group/guild) meetings the other day and one of the folks asked a question about a team member they were coaching. I’ll try my best to capture it—
I have a team that I’m coaching who suffers from lots of WIP and they carry over between 30% and 40% of their stories per sprint. I’ve tried bringing up various ideas to help with this, but the team lead, a very strong character, always disagrees with any of my suggestions/ideas. They simply override me and consider it a non-problem. What coaching ideas do you have to change this?
The Herd group brought up quite a few suggestions, for example:
Better backlog grooming
Smaller stories
Discussion around WIP, Lean, and the importance of getting things done
Impact on forecasting and stakeholder trust
Talking to the persons manager
Perhaps trying Kanban, etc.
Everything we said the coach basically replied: Done that, tried that, didn’t work, give me something else…
If you know anything about me, you know that I’m a Rush fan. So, this article plays a bit of a homage to the song—Big Wheel. RIP Neal Peart.
This is a relatively short post, but an important one. I want to highlight an initiative that’s been going on for a while by Mark Summers and a bunch of other smart folks to define a model or tool for what solid, robust, and professional Agile Coaching skills look like. They call it the Agile Coaching Growth Wheel.
They’ve established a website called http://whatisagilecoaching.org/ Where you can find a description of the Wheel and other supporting information.
What I like about the tool is the depth and breadth of it. For example, the service-oriented aspects. Or the fact that it contains a consultative or advising component that I think is missing from some other models. Let me explore my previous go-to models before highlighting the differentiators in the Wheel.
I got into a debate with a coaching colleague the other day. Well, debate, disagreement, argument, and other terms could apply. We kept it respectful and, in the end, I believed we agreed to disagree.
I’ll call my colleague, Ken.
We used an analogy as part of our discussion that I’d like to share. Here’s the analogy—
Meniscus vs. TKR?
I’ve got a problem with my knee. I’ve done the web research and self-diagnosed that I have a partially torn meniscus and I want some simple surgery to clean-up my knee and fix the meniscus.
So, I start looking for the best surgeon I could find. The best “knee-person” out there. And I found her. She’s expert at all sorts of knee surgeries from the meniscus to total knee replacements. Having performed thousands of successful surgeries.
I scheduled a visit to explore the surgery. And she runs some tests (X-rays, MRI, etc.) on my knee in advance of our discussion.
I enter the discussion telling the doctor what I need. I even go so far as telling her when to schedule it. As, clearly, I’ve determined what wrong and what to do about it.
She listens patiently but tells me clearly and firmly that I need a total knee replacement. That my knee is irreparable with anything other than that sort of corrective procedure.
I argue with her. And I insist that I simply want the meniscus repaired. I’ve made up my mind AND I want her to do it…
Ask vs. Need
Clearly, in this example the doctor has a decision to make. And I don’t think it’s that hard. The options are:
