That allows two things to happen: First, instead of looking for a "coach" in general, an organization can instead figure out what kind of coaching it needs - teaching, mentoring, conflict resolution and so on - then find a coach who can self-assess to a skill set to meet that need.
Second, it admits that not every coach will have every skill, which encourages more paired-coaching assignments. The Agile Adoptions that I have seen "stick" tend to correlate to pairs of coaches - one technical, on more focused on organizational change.
Skepticism abated, I move from theory to practice and look for a story of agile coaching in action.
Agile Coaching in Action: Don't Always Do What You're Told
According to Meike Mertsch, knowing what needs to be done, regardless of the official request, is part of the essence of agile coaching.
Meike Mertsch is a consultant and coach from Germany. When I asked her for a coaching story, she talks about a team that asked her to teach estimation. In a blog post on the subject, Mertsch recalls the team calling a meeting to discuss and estimate 80 different 'stories.' Most weren't actionable, though; instead of stories, the cards were full of values such as "more intuitive" or "user friendly."
While the official "ask," as it's called, was learning estimation, what the team actually needed to do was a whole lot of figuring out what to build.
Early into the meeting, Mertsch realizes this difference, which she describes as "a knot in the stomach." Instead of continuing to teach on estimates, Mertsch suggests the product owners come up with action items for the next spring only &mash; that is, a handful of directly actionable ideas.
The group dispersed and reassembled later that day, working through a small number of reasonably well-defined tasks. Mertsch didn't teach about estimation that day, as other coaching was needed.
Going back to the model, Mertsch needs to know which skills she needed at a point in time, despite the official "ask", and needs to be able to quickly shift from teacher mode to facilitator and back, according to various kinds of expertise. That's the top and bottom of the model. As it's not possible to be an expert in every area, she also needs enough self-awareness to know when to bring in help.
Pinning agile coaching down to a precise definition might not be possible, but at least this gives us the tools to talk about it.
Agile Coaching Philosophy: Apply What's Needed
I may have been too hard on the old friend I introduced at the beginning of the story. His expertise is coding, so when he went to a client with its own private programming language, he contributed where it made sense: Helping build a harness for unit tests, then pairing to help the programmers write testable code.
Sign up for MIS Asia eNewsletters.