Agile Coach = Agile Secret Police?
He's not the first to voice this opinion. And, though not a proponent of Agile, Tyma has done XP, so perhaps there's a basis for his view that "an Agile Coach is not really a 'Coach' so much as a hall monitor or a secret police officer." He also complains of inappropriate zeal: "It has all the makings of a religion."
The term "Agile Coach" has evolved in recent years to cover a number of roles, and a coach may wear multiple hats, for example:
- Extreme Programming coach (engineering practices)
- Scrum Coach (requirements, self-organization and team leadership)
- Organizational Change leadership (working with management for Agile-friendly change)
Paul Tyma is a software engineer and writer for JavaPro magazine, Dr. Dobb's Journal, and he speaks annually at the Software Development conferences, so he's a peer to Agile evangelists like manifesto signatory John Kern and IBM's " Practice Leader Agile Development," Scott Ambler. It's unlikely that Tyma hasn't heard the pitch for "Agile Coaching" - he just isn't buying it. His reasoning?
"I'm just a bit skeptical I need a 'coach' to make sure I'm standing up correctly at my daily meeting. Some jobs appear only when business is good and are the first to go when times get bad. If we assume that eventually, times always get bad - then I guess we'll find out if Agile Coach is one of those."Fair enough - time will tell. In the meantime a number of "coaches" have taken up the conversation in comments on that blog entry. One, William, agrees that the role can be misused:
"I'm sure you're right that, in some organizations, coaches are in effect agile secret police. I think that's foolish, and a waste of money. The only clients I take on are ones where the team is interested in trying agile methods to see how they work for them. Like my boot camp coach, I help people improve in things they care about improving. You can create the appearance of change with externally imposed harrassment, but it's not real change, and you don't get the real benefits."William goes on to point out that a coach can actually work for the team, countering Tyma's assumption that coaches are agents of management: "There's also something I can do that employees generally can't: I can tell managers when they are the issue, when their well-intentioned efforts are screwing up the team. I end up doing this quite a bit."
William goes on to point out that a coach can actually work for the team, countering Tyma's assumption that coaches are agents of management: "There's also something I can do that employees generally can't: I can tell managers when they are the issue, when their well-intentioned efforts are screwing up the team. I end up doing this quite a bit."
I couldn't agree more. Another aspect a coach adds to the mix is a sense of objectivity. He or she is probably more objective than people involved in the project on a day-to-day basis, hence able to quickly assess a certain situation and advise on taking certain actions to improve, without being held back by politics for example.
Ultimately, as with all approaches, it can be handled with sensitivity or with the hammer of Thor. But also, the participants can be open and inquisitive, or closed and cynical. The latter is also an obstacle for adoption, and can turn well-meaning coaches' efforts into quasi-gestapo evangelism in the eyes of a team. Cynicism is a communicable disease.
Coaching can help a new team
J Aaron Farr
When you're trying to figure out agile yourself it can be difficult to self-analyize. You also only guessing at how best practices are actually implemented. Having an "expert" to assist can speed the process along and help teams avoid classic pitfalls.
This is true of any consultant. If your team is picking up a new technology, you can bring in an expert to do training and coaching. Of course you can do it yourself, it just takes longer and you face the risks alone. Bringing in a process consultant is no different. And all the normal consultant practices exist -- the position should be temporary, clearly defined, and eventually unneeded.
Mediators assume the fight is on
UNTIL, someone decided HEY LETS have a BIG MEETING and get all the Non-Java people together with the Java people and HASH THIS OUT (when there was no visible or necessary conflict even on the support side)
Needless to say there is no point in doing hibernate anymore because teams of people with 10 year outdated skills dont know what it is and will shout it down because mgmt *under the guise of mediation* created a battle royale that DID NOT exist in reality to satisfy its own curiosity about the differing opinions it didnt understand.
I can see an agile mediator doing the same thing, its like a marriage counselor sitting around waiting for a fight that wouldnt have happened (or would have been resolved much better) if not for the assumption that it would happen and the UN of process needs to be there to stop the shooting.
Re: Agile secret police -> Management-imposed Agile
Often this sort of dynamic occurs when well-meaning management is attempting to implement an agile-friendly change in the organization, but is doing it by fiat.
Actually, it can just as easily be mgmt trying to implement agile with everyones input then never empowering anyone on any team to actually MAKE A DECISION which is worse that BY FIAT because it falls flat
Re: Agile secret police -> Management-imposed Agile
Re: Mediators assume the fight is on
Hmm, so what have I been doing all this time?
Or maybe I'm just sensitive. :)
Ok, so many projects may not need a coach. If you're doing XP "perfectly" you probably don't need one. Does anyone know of such a project?
Even agile teams don't automagically transform into empowered, self-directing teams overnight. In some organizations, developers have been trained to be subservient and docile. It can take a while for teams to reach a point where they can stand on their own.
I do agree that the goal for any coach should be to work themselves out of a job. :)