Such a simple question, but it invokes a lot of opinions and debate.
My answer to this simple question is an equally simple answer. For me, much like a football coach is someone who coaches football:
An Agile coach is someone who coaches Agile
Please forgive this tautology for one moment, and allow me to explain. We (in the “Agile community”) often over elevate and complicate the Agile coach role. A team, or organisation, wants to derive benefit from “Agile approaches”, or get better at doing so, and as such want to bring in a coach who knows how to help them in this pursuit. An Agile coach. They want, and expect, that the person is able to bring with them a focus on using Agile philosophies to achieve improved outcomes in terms of software delivery and teams.
It is good to know what you are hiring, and what the coach is “selling” in terms of the nature of the approach and expertise they’ll bring to the table.
Much of the controversy with this stance is that “Agile” is not a goal, but a means to an end. So, the argument continues, we shouldn’t be coaching “Agile”, rather we should be understanding what the person/people/organisation wants to achieve, and work with them to achieve it.
I agree wholeheartedly with this, and have even written/spoken a lot about the folly of having “Agile” as a goal, whether it’s “being agile”, “doing Agile” or “working in an agile way”. It’s always important to identify the actual outcomes we’re aiming for and work towards them — “Agile” is way too broad in scope and interpretation for that purpose.
However, I think it’s ok to say an agile coach “coaches Agile”. Once a football coach is embedded in a club, they are no longer thought of or referred to as a “football coach”, just a coach. They are not teaching the players how to play football, they are trying to get the best out of the players and the best results for the club.
The same ought to go for an Agile coach. They are a coach whose leaning, skills and experience are around Agile principles and techniques. This does not make them a one-trick pony. On the contrary, “Agile” encompasses almost every aspect of software/product development, from a process, practice and human interaction standpoint.
Another thing to point out here is that I would not expect that each and every Agile coach knows every aspect of Agile and related philosophies, and has worked for years in “Agile environments”. Why do we expect an individual Agile coach to embody so much? I would expect each and every Agile coach to be different, just as I would expect each and every developer, business analyst, tester, product owner — or any other role you care to mention — to bring their own unique blend of experiences, number of years of experience, theoretical knowledge, practical skills, and other human qualities and attributes to the table.
Football clubs know this. They don’t hire one coach. They have goalkeeping coaches, striking coaches, defensive coaches and more. Teams of coaches. Some young and relatively inexperienced, with no trophies to their name, and some older who have won silverware in different leagues and countries. Each coach specialising in different areas of the game of football. In the software arena, agile coaches might specialise in technical practices, organisational change, team performance, facilitation, and more. Why should we expect every single coach to be able to do all of those things?
When I was younger and living in Dublin, I became the coach for a local ladies 5-a-side football (soccer) team. I had never coached a team of any kind in my life, let alone a ladies football team. This did not stop my role from being “coach”, or the players calling me, or referring to me as, “coach”. I figured out what I needed to do, and what was expected of me, as I went along. I was a million miles from being the finished article, and the reality is there is no such thing. Anyone who thinks they are the finished article, or even believes it’s possible to be that, in almost any discipline, is likely to become increasingly less effective.
I think we often (wrongly) elevate coach roles in software development to be the exclusive domain of folks who’ve been there and done that over at least 10 years in the industry. Instead, in my view, we ought to be looking at what the coach’s role is — what it is there to achieve — rather than put the individual on a pedestal, with unrealistic expectations, as someone who is going to create benevolent disruption and magic. We should all be working and growing together, regardless of our role or speciality, and supporting each other in that.
So, for me, an Agile coach coaches Agile. That’s it, and that’s OK. We just need to understand why we want someone in that role, and make sure others who will be working with that person also understand the what and why of the role. We need to be able to articulate to ourselves, and the coach, what we’d like them to achieve in the short and long term, and support them in doing so. As we do with every other role in the organisation.