This installment of the Ask an Agile Coach series is a question normally asked by persons outside my field, but lately I have been asking it myself:
What is an Agile Coach?
Good question. I am not sure anymore.
The more I encounter others who call themselves Agile Coaches, the more I think I may not be up-to-date on what that is supposed to mean.
As I have historically interpreted it, an Agile Coach is someone who first actually established a proven track record of successfully leading a series of Agile adoptions as part of the actual teams. The insight, perspective, and expertise gained through that effort are what enable them to coach others. Multiple Agile teams in varied settings challenges what a person “knows to be true” and (hopefully) beats some humility into and the dogma out of them.
I have been under the impression that an Agile Coach also understands software development and the technical practices that support an Agile team. One must understand why testing, automation, code review, and pair programming exist. One must know what it feels like to work both with and without these things, know why professionals should adopt these practices, as well as when one or more of them are not a fit for the culture. It must be very strange to have management bring in a coach who tells you to do these things but cannot show you how.
I also thought that coaches should understand how to apply an Agile process in a way that stresses cross-functional participation. If what a coach is doing isn’t helping the company to function more effectively as a whole, I fail to see the point. Agile Software Development is neither a defense mechanism for engineers nor a tool for more effective exploitation by management.
It feels weird to have to point this out, but I believe a coach should understand Agile estimation and planning techniques, especially the ones laid out in Mike Cohn‘s books. Estimating and planning are among the most painful parts of software development, and one of the most fulfilling parts of coaching for me has been mentoring groups in Agile estimating and planning.
I also think an Agile Coach is someone who can say no. Agile Software Development is a challenge at best, and a cultural nuke at worst. There are places where the introduction of Agile process and practices would wreak havoc. I suppose the toughest part of this is that it requires a willingness to turn down paying work.
I am seeing things these days that make me think my idea of what an Agile Coach is might be incorrect. If it is, I might need to stop using that word. It doesn’t mean what I think it means.
Your definition sounds pretty solid to me. However, words mean what people think they mean. If “agile coach” has come to mean something more watered down, or has been twisted to mean different things to suit different agendas, you have to decide if that’s what you identify with.
Sadly, this is the part of your brand you have little control over.
I think you strike at the heart of it; the words have come to mean something different, and I don’t identify with this new meaning. To be fair, the term may be coming closer to classical definitions of coaching. However, I haven’t seen great results with classical coaches trying to make an Agile adoption succeed; in fact, quite the opposite.
A most excellent post Barry. One that aligns with my beliefs entirely. I have been trying (unsuccessfully) to get people to change the term Agile coach to Agile Mentor. This is because a mentor captures more of the essence of having “been there, done that, got the Scrum certification”. Coaching might well be part of what the mentor offers, but to some coaching purists the best coaching is carried out when the coach is being non-directive. Anyway, its good to hear that people are actually thinking about this and maybe we can start a revolution.
Mark Buchan
Executive Coach
Thanks for replying Mark, I see you’ve been feeling some of the mismatch as well. Mentoring is certainly a large part of what I do, but I mix in hands-on participation here and there to stay technically relevant as well. I’ll keep sharing some of it here, figuring out how to convey it is certainly a work in progress for me.
Useful post. The role as you describe it, although often labelled as “Agile Coach” strays far from the accepted definition of the term “coach” as used in e.g. Life Coaching, Executive Coaching, and forms of Sports Coaching as exemplified by e.g. the folks at The Inner Game.
In particular, these other fields suggest that domain knowledge (e.g. technical experience) is more often a HANDICAP than an asset.
Unless we have a good reason to stray from that accepted definition (I can’t think of a good reason to do so, off hand), what say you to the suggestion that we try to remain congruent with the use of the term “Coach” in these other fields?
– Bob
Thanks for your reply, Bob. I definitely agree with you on the mismatch in what’s often described as an Agile Coach and a coach in pretty much any other setting. A follow-on item I have been contemplating is that people who fit that classical coach definition (in that they have almost no domain knowledge) have made some pretty fantastic wrecks in Agile adoption attempts I have seen.
After that post, I decided to stop using “Agile Coach” as a role of mine. The question now is how to phrase what I do. I like that line from your Twitter bio: “Specialist in avoiding the many pitfalls of Agile and Lean adoption” Lo, they are indeed many.
Comments are closed.