Finding ways out of the dependency trap
25 March 2015
While directly or indirectly helping companies adopt or refine Scrum, I have noticed a tendency among many ScrumMasters that has the potential to turn into a subtle but destructive anti-pattern. Sadly, ScrumMasters still lack an official ethical guideline, and as a result many novices are unaware that they run into a distinct set of contradictions that can lead to an unhealthy codependency between themselves and their teams. It's relatively easy to fall into that trap, and I was certainly guilty of this myself at times 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 ScrumMaster that is not immediately obvious to most people. On the one hand, the ScrumMaster 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 ScrumMaster to solve problems and the ScrumMaster depends on the team's helplessness, on their dysfunction. If you think that the ScrumMaster'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 a ScrumMaster. The pattern itself stays the same.
By definition, a ScrumMaster 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 the 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 ScrumMaster 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 something during the next sprint retrospective (which will be overly colorful and innovative, because the ScrumMaster didn't spend any time tackling larger organizational issues). Instead of long-term individual and collective growth, everybody is fixated on finding things the ScrumMaster 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 ScrumMaster is teaching people mind-sets and behaviors that elicit lasting change, not temporary fixes to reappearing symptoms. In essence, it comes down to the mind-set 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're a ScrumMaster, keep this in mind: It is possible to miss a Daily Scrum. It is possible to miss a sprint planning, a sprint review, and -- yes -- even a sprint retrospective. 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 Scrum 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 toward 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 ScrumMaster not as a single person but as a mind-set that 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 Scrum team should entirely be without a ScrumMaster. The ScrumMaster 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 ScrumMaster for a limited amount of time.
And please don't fall into the other extreme of the ScrumMaster 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 mind-set. 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 mind-set. 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 into 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 a team member resolving an impediment will lead to an experience of 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 ScrumMaster and how many by someone else. Let facilitation of Scrum meetings rotate among 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 will 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 Scrum meetings go on even though 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 in the direction of ethically sound Agile coaching.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.8 (20 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.