Bob Galen

A good friend of mine did a survey a while back asking a simple question: Can the Scrum Master “fire” a team member if they’re an impediment?

The word fire in this case was ambiguous. It either meant fire directly, as in termination, or it meant simply removing them from the team, with or without having another place for them to land.

It created quite a stir of comments, and I think the final numbers were 65% against removal and 35% for, with approximately 200 respondents.

It absolutely floored me that 35% of the respondents thought it would be OK to remove a person from the team. I likened it to voting them off the island. I also found it alarming that many of the resulting comments seemed to place operating in Scrum above operating within a human system. That is, it seemed to forget the Scrum Values of respect and courage—in this case, respect for the individual and the courage to coach and mentor them.

As you can probably guess by now, I weighed in on the no side of the fence, for three main reasons:

1. I don’t believe many Scrum Masters have the experience and training to undertake an HR action like this. It’s certainly not in the role’s description in the Scrum Guide.

2. I don’t believe people are impediments. I have the same visceral reaction when folks refer to people as resources. People are people, and they are wonderfully unique. I really don’t care for folks categorizing them in such a way as to make actions appear less severe or impactful.

3. I think there are conditions in organizations adopting Scrum that are beyond the Scrum ecosystem. And people and their performance are certainly one that is on the edge of the ecosystem, if not entirely outside of it.

For example, what if the person has an illness that is affecting their performance and team interactions? Or what if the team isn’t interacting effectively with the person because of a diversity issue? Or what if they recently had a death in the family and are struggling with grief? Or what if…

What about team impediments? I think of impediments as anything that prevents the team from reaching their Sprint Goals. But it excludes the people on the team, as people are not impediments to be excised or removed.

Instead, I think they are coaching and servant-leadership opportunities for the Scrum Master. They require respect and care, without reading anything into their behaviors. And they require the Scrum Master to clearly understand their own situational and experiential limitations.

When they are out of their depth, they need to immediately be willing to go get some help, for themselves and for the team member. And where might that help come from?

It might come from the management/leadership team members and from Human Resources. Even if these folks don’t understand Scrum, they are in a better position to help with the person than the Scrum Master often is. And at some fundamental level, the Scrum Master needs to let go, trust, and allow the system to figure things out.

The role of the Scrum Master is a challenging, rich, important, and often frustrating one. And it includes lots of surface area. But it also includes being vulnerable and knowing when to ask for help. And I believe this is, in essence, one of those situations.