Guest post: What is an Agile Coach?

Recently a friend asked about the definition of the title, “Agile Coach.” Googling “agile coach” informs me that there are about 205,000 pages with that term. Obviously the term is in widespread use.

I don’t typically call myself an Agile Coach, though I’ll use that term informally if it’s the term used by those with whom I’m having a conversation. Instead, I call myself a Software Development Coach. To me, the goal is developing software more effectively, not becoming Agile. Agile processes and practices happen to be excellent tools for effective software development, but lousy goals in themselves. Or so it seems to me.

This morning, I got a call from a recruiter looking for an Agile Coach for a client. They were a bit unhappy when I gave them my daily rate. “The client has a budget and will never pay that much.” When I asked what rate they were expecting, they said $50/hour, all inclusive.

I made more than that a decade ago as a contract programmer. I cannot imagine finding a competent experienced coach for that rate. I’m sure that you can find a body to sit at a desk, though. Is there value in that?

This low rate, and the fact that cost is a primary factor, but value isn’t even mentioned, makes me wonder about what this role of “Agile Coach” has come to mean to organizations looking to hire them.

If the value received and the cost paid are nearly equal, then cost is of critical importance to avoid spending more than the value received. If the value received is an order of magnitude more than the cost paid, then variation in the cost has much less affect on the Return On Investment. This is very similar to the point that Tom DeMarco made in his article “Software Engineering: An Idea Whose Time Has Come and Gone?” [IEEE Software, July/August 2009] “This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects.”

I fear that for many large companies the generic “Agile Coach,” and the Scrum specific “Scrum Master,” has become a term for a person who neither programs nor tests software, who is added to a development team to make it Agile. It’s as if you could sprinkle some pixie dust on your development teams to make them more productive, or whatever advantage they can see in the adoption of Agile.

Is that what “Coach” now means?

I suppose I shouldn’t be so surprised. The meaning of “’instructor/trainer’ is circa 1830 Oxford University slang for a tutor who ‘carries’ a student through an exam” based on the Hungarian word for a carriage. It’s clear that some people have always wanted to hire someone rather than learn to do for themselves.

Certainly there’s value in getting one project done a little more effectively than you might otherwise. If you can hire someone to work full-time on a project and guide the actions the team to improve the effectiveness for the duration, then I expect you’ll get enough marginal value that you might get some ROI. I’m skeptical about accomplishing that with the most cut-rate of coaches, though.

The true value of coaching, however, is to build the capability of the existing team. Rather than making choices for the team, the coach provides guidance about the choices available, perhaps making recommendations, and encouraging them to consider the options and choose their actions. The coach teaches the team about techniques or tools that increase their available choices. The coach offers observations about the team’s activities, and helps the team make it’s own observations and reflect on them. The coach helps the team articulate the results it wants, and generate courses of action to achieve those results. The coach partners with the team on the coaching process, but allows the team to exercise its own judgement about the software development practice. The coach does not become a member of the team, but endeavors to wean the team off of the need to consult with the coach on a regular basis.

There are consultants whose business model includes making the client more dependent on the consultant. That, to me, is not coaching. And that’s not the model of consulting that I choose.