Note: A version of this post was first published on the Scrum Alliance website.
While directly or indirectly helping companies adopt or refine their agile approaches, I have noticed a tendency in many Agile Coaches which has the potential to turn into a subtle but destructive anti-pattern. Sadly, Agile Coaches still lack an official ethical guideline, and as a result many novices are unaware that they run into a distinct set of contradictions which can lead to an unhealthy codependency between themselves and their teams. It’s relatively easy to fall into that trap and I have certainly been guilty of this myself when I first started out.
The problem starts with the fact that there is a subtle but important contradiction associated with the role of the Agile Coach which is not immediately obvious to most people. On the one hand, the coach is supposed to help the team and the company at large. On the other hand, she is supposed to teach the team how to self-organize. Now, if your job is to help people, what do you do when people don’t need your help? Taken to an extreme, it may seem like the whole basis for your existence in a professional field suddenly becomes void. And that’s precisely where a reinforcing cycle of mutual dependency starts.
What Does Agile Codependency Look Like?
Agile codependency looks like this: the team depends on the coach to solve problems and the coach depends on the team’s helplessness, on their dysfunction. If you think that the coach’s identity is reinforced by making problems disappear for others, then you’re almost there. I believe it’s easy for teams to get caught up in this belief system since, quite often, team members have ingrained habits of waiting for someone else to take action. It used to be a manager before. Now it’s an Agile Coach. The pattern itself stays the same.
By definition, an Agile Coach is supposed to be a servant-leader. However, in the context we are examining the “servant” part can be a bit misleading. To truly serve you don’t want to create an imbalance by having team members constantly depend on your supervision. Quite the opposite. You want them to be as free as possible from constraints. And those constraints include your own actions. If you solve each and every impediment for the team, do you think they’ll learn how to solve impediments effectively themselves? (The answer is probably no, except when you’re working with exceptionally motivated people who resist your pull to make them depend on you.)
What Are Results of Agile Codependency?
The results of this agile codependency are disempowered teams and recurring impediments blown out of proportion. The team is waiting for someone to take initiative and sort out their issues. Conversely, the coach desperately needs the team to validate the reason for the sheer existence of his role. And if no real issues pop up during the Sprint, team members better make sure to find anything during the next Retrospective (which will be overly colorful and innovative, because the coach didn’t spend any time on tackling larger organizational issues). Instead of long-term individual and collective growth, everybody is fixated on finding things the Agile Coach can take care of. The irony here is that, even when you’re deeply caught up in this pattern, you can still claim to be doing textbook Scrum!
The art of being a great Agile Coach is teaching people mindsets and behaviors which elicit lasting change, not temporary fixes to reappearing symptoms. In essence, it comes down to the mindset you hold while coaching. You’re acting from a place of unconscious fear when you feel like doing your job well means losing that same job at some point in the future. You’re acting from a place of strength when you know that people who evolve will in turn inspire growth in you and new opportunities will arise all the time.
So if you are an Agile Coach, keep this in mind: It is possible to miss a Stand Up. It is possible to miss any Agile meeting. When you suddenly get violently sick and your team can’t at least improvise its way through a Retrospective, then you’ve got a serious problem. Has your team ever skipped a meeting because you weren’t there? Ever left impediments unresolved because you were out? Ever shied away from talking to someone in the company because you weren’t there to hold their hand? Those are your impediments right there.
The aim should be to equip each and every team member with the skills they need to effectively hold meetings and resolve challenging issues on their own or as a team. That’s the way towards true self-organization. It varies how far team members are willing to go with this, of course. Some will be excited and want to learn more while others only want to get back to doing “real” work. That’s fine. But try to think of the Agile Coach not as a single person but as a mindset which can be propagated within a team. The people involved need to learn. They can’t do that if they don’t get the chance.
I’m not saying that every mature team should entirely be without a coach, however. An Agile Coach is an extremely powerful ally and always offers a unique perspective to a development team. It’s great to have someone who has the time to reach further into the organization, has an eye on how teammates communicate instead of only seeing what is being communicated, and is able to provide new ideas and impulses. That won’t change. I believe the aim is not to abolish the role in general, but to coach a team until it is at least able to perform reasonably well without a coach for a limited amount of time.
And please don’t fall into the other extreme of the Agile Coach who never does anything. The one who only asks wise questions. Who never takes the load off a team in times of pressure. Just don’t be that person.
A Way Out of Agile Codependency
In order to address agile codependency look for improvement in these four areas:
Individual mindset. Ask yourself: Why is it so important for me to help others? To what extent does my identity rely on the act of helping or solving problems for others? What’s in it for me?
You may need to reframe your individual purpose from “helping people” to something larger that doesn’t involve dependency.
Shared mindset. Ask your team: To what extent is it easy to let someone else help us? Are there areas where we don’t want to grow, because it’s uncomfortable? Could we take full responsibility for our actions and are we fully skilled to at least deal with what’s coming our way?
You may need to reframe the team purpose to something that includes authentic strength as well as sustained individual and collective growth.
Individual behavior. Take note of your daily interactions. If you act as the communication hub for team members, slowly give up control and teach healthy communication patterns.
When you try to resolve an impediment, ask yourself “Could someone else on the team do it? Why aren’t they doing it? Is me doing this simply the most effective option or could someone else grow by doing it instead?” Know that an impediment resolved by a team member will lead to experiencing personal success, growth and self-efficacy which in turn are preconditions for developing personal and/or team responsibility.
Social behavior. As a team, keep a list of impediments and see how many of those have been resolved by the Agile Coach and how many by someone else. Let facilitation of meetings rotate between team members so everybody has been in the facilitation role at least once to know what it’s like. This enhances the sense of responsibility for these meetings.
As always, success won’t come overnight. If you really want to move away from agile codependency, ease into the new situation and be as transparent as possible about it. Your colleagues will probably not be used to this change and need some time to adapt. Don’t simply demonize the old behavior style. Instead, find compassion for yourself and others, acknowledge why the pattern worked for you at that time, identify a healthier and more sustainable way of being, and then gently develop into it.
When meetings commence even when you can’t be there, when team members see an impediment and tackle it right away only asking your for backup when they truly need it, when communication flows freely without any unnecessary proxies, then you’re making great steps into the right direction of ethically sound agile coaching.