Coach Addiction

Agile coaches help teams. Right? Having a coach to help guide a team means they are more likely to become a successful, high performing agile team. Right? That's why organisations are prepared to pay for agile coaches. But is there a down side to coaching? Can coaching hinder a team, rather than help it?

Imagine, if you will, a team. They are on about sprint 20, you are their new agile coach, taking over after the last one left. You are observing a retrospective and they are doing what they should be doing - working out what went well, and what didn't. "Why", you are thinking, "do they need a coach after 20 sprints? They seem to be doing fine". Then they get to the "what should we change for next time" bit, and all eyes in the room turn to you. "This is where you, as our coach, tell us what to do so we can get better" they say. "Work it out", you say, "Self-organise around the problem and solve it". "No", they say, "you have to tell us what to do". Then you notice that there is no sprint planning scheduled for the next sprint. "That's your job" the team says. "You tell us what to do and we do it". Welcome to the dark world of coach addiction.

When coaching, the goal is always a team that self-organises. They identify and remove problems themselves. When we first start coaching teams, they don't know how to self-organise so we tend to start in a very directive way. We are teaching them the basics of agility and generally stepping in to show them how it's done. With our love for Japanese terminology, we often refer to this as the "Shu" state - learning the forms. For teams in this state, you really have no choice. You have to be directive.

The next state is "Ha" where they learn to start blending existing techniques in new ways to solve problems, rather than just relying on the basic techniques. The final state is "Re", or mastery, where they are inventing their own techniques from scratch. In the Ha and Re states, the job of the coach is not to be directive but to act as more of a mentor and guide. That way the team learns to innovate by itself. So directive for Shu, then back off to a mentor role for Ha and Re.

It's not quite as simple as that though. You need to back off into a mentoring role before the team gets to Ha. You need to back off before they are ready for you to back off. Why? Because if you don't and you stay 100% directive, the team will never reach Ha. They will be stuck in Shu forever because you aren't giving them the space to learn to innovate. If you always give them the answer, they will never learn to think for themselves. They will develop a coach addiction.

I have seen this quite a few times now, where a well-meaning coach, particularly when under pressure to deliver results quickly, over-directs a team. Sure, giving them the answers will make them improve faster. This ties into the responsibility trap I talked about before - the team needs an answer, they are under pressure, I'll give them the answer so they can keep moving. Highly directive coaching gets results fast, but without the ability to think for themselves, that team is totally reliant on the coach for any improvements. If the coach isn't there, or moves on, the team is stuck. They can't innovate. Any agility they have will quickly evaporate, or worse it will stay, locked into a rigid "this is the process we follow because it's what the coach told us" kind of mindset that can't adapt to change.

This means that the coach can never let go. They are stuck with the same teams forever and there is a limit to the number of teams a coach can successfully coach, particularly teams in the Shu state because they need a lot of work. What about the rest of the organisation? There are teams out there wanting agility but the coaches are all stuck with existing agile teams. Hire more coaches? That gets expensive and there aren't that many coaches out there anyway. The only way to scale coaching to the enterprise is to be able to lift teams up to Ha and then leave them. Let them direct their own learning. Be there to guide where needed but you don't need to be there all the time like you do with Shu teams.

We need, as coaches, to learn to let go and give our teams the space to learn. That will mean letting them make mistakes. Let them try something, learn from its failure (or success) and guide them towards a better choice. Don't dictate all the time. This is also why I have some issues with the concept of a coach with delivery responsibility. On one hand you want the team to make mistakes and learn for itself, on the other hand your job depends on directing the team so they can deliver fast. That's two very different goals and that makes a coach's job very difficult indeed.

Yes, this will take longer. Yes, they will make mistakes. Yes, they will waste time going down wrong paths and having to back track. Organisations need to learn that a really fast transformation with no self-learning built in is not a scalable or sustainable model long term. It will get results quickly, but those results will evaporate just as quickly when the teams don't have a coach on tap 24/7.