AGILE COACHING LESSONS
It is important for Agile coaches to understand that coaching is an exercise in authority dynamics. Contrary to popular belief, it is not enough for some C-level person (someone capable of signing off on a big check) to authorize you.
The teams you coach must actually consent to being coached.
Repeat: consent to being coached.
It is important to ask the team for consent before facilitating their meetings. And respect the “no thanks”… if it comes.
Any attempts to coach teams without their consent amounts to a dysfunction you are definitely party to creating. The organization is trading one set of dysfunctions for another. You are a player in that drama. You are an enabler.
[NOTE: In earlier lessons the link between self-organizing teams and the real-time distribution of authority by and between the members is explained. If you are unclear on this essential concept, skip back to previous lessons and catch up.]
Yes, we all know the “Shu-Ha-Ri” model popularized by Alistair Cockburn. The “Shu” stage, or beginner-state, is the typical excuse for inflicting help on teams. The idea is that “they are in the Shu-state. They know nothing, and must be taught. We must prescriptively model it for them.”
Really? Does that actually work well long-term?
Teams are typically in the Shu-stage for a very short period of time. What happens after that?
Imagine this: Assume that absolutely ideal conditions exist…these teams want to try Agile, and they consent to being coached. So far so good…
Question: How long do you plan to keep on playing the lead in their process? How productive is it for you to continue in this manner for more than two or three weeks?
Answer: “Not very.”
Here is why:
- You are setting yourself up as the single source of truth about Agile and what Agile looks like. You are not.
- You are not building any kind of capacity in the organization to reach a self-sustaining, freestanding state of Agility. Instead you are dominating the team’s entire experience of Agile.
Now let’s click down one level, and assume that the typical conditions exist, namely: the teams never consented to do these Agile practices. As such, they never really consented to your “help” either.
The following aspects are also now true:
- You are symbolic of management. You represent management. You are part of a “solution” created by management, one the solution providers (the software developers) are forced to accept. The have no option– except to quit. This creates almost automatic dis-engagement. The reason is simple: you are turning them off with your presence. You are party to a mandate of specific practices.
- You are “inflicting help” on people who never asked for help; in effect you are trying to “fix” them. This is a failure pattern. It’s a recipe for creating resentment.
- You are authorized by management; as such you are perceived as an authority figure. The team, now quite disengaged and likely feeling more than a bit resentful without knowing why, will now simply wait for you (the authority figure) to explain everything. They will wait for you to make decisions that properly belong to them. They literally cannot and will not self-organize because there simply is not enough authority to go around.
Disengaged, resentful, unwilling. This is the very opposite of what a self-organizing team looks like.
Can you see why?
How do you, the Agile coach, get out of this mess you are in? The solution is very simple:
First, make sure the teams are consenting to doing these Agile practices.
Next, find some people in the organization who wants to try doing facilitation, the kind you deliver.
Then intensely mentor these new facilitators, so they learn by watching, and by doing.
And then… get out of the way.
Essay: Triggered By Process Change (link)
Essay: The Anxiety Iceberg (link)
Agile Coaching Lessons:
If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or following me on Twitter and/or joining the OpenSpace Agility group on Facebook