If you’re a Scrum Master, and you have one person on your team who’s causing trouble for the rest of the team, should you have the person removed from the team?
Someone asked this in a Scrum forum I belong to. A lot of people posted opinions, on all different sides of the issue. Most of them said that it’s not the Scrum Master who decides what to do about a team member who’s “causing trouble,” it’s the team, which is true.
But if you’re ever in this situation, that’s not the first thing you should think about. The first thing you should think about is whether it’s really one team member who’s causing trouble for the rest of the team, or whether something else is going on.
Here’s an example. A few weeks ago, I was observing a Scrum team that had just noticed a baffling bug in the basic infrastructure of the project they were working on. Everyone agreed that they should fix this bug before continuing to work on the stories they’d committed to for the sprint.
But they didn’t agree on how to investigate and fix the bug. One team member thought that two team members should pair up. Everyone else on the team thought the entire team should mob. After some discussion back-and-forth, the one dissenting team member went along with the decision of the rest of the team.
Suppose that this one team member did this a lot, that is, disagree with the rest of the team. Is that team member causing trouble? No, not necessarily. If that team member is recommending what they truly think is right for the team, then they’re not causing trouble. In fact, they may be helping the team, by getting them consider alternatives that are different form how the group is thinking.
Whenever you have one member on your team who you think is “causing trouble,” or other team members think is “causing trouble,” the first thing you should do is observe. Observe the team and everybody on it. Pay attention to who talks to whom, who interrupts and who gets interrupted, who has ideas, whose ideas and suggestions help the team keep its commitments.
The second thing you should do is synthesize your observations. Is that one team member really causing trouble? Is the team member the newest member of a long-standing team? Is the new team member less experienced with Scrum than everyone else? Does everyone else on the team come from a different culture, background, conversational style than the one team member? Or, maybe, are some of the other team members treating that person badly? Are they all ignoring and dismissing that person?
The third thing you should do, is create a set of neutral observations you can give to the team. For example, “I’ve noticed that not everyone is getting a chance to finish what they’re saying.” Or, “I’ve noticed that not everyone on the team shares the same conversational style; some of you are turn takers, and others of you are overlappers” (or whatever you notice). Or, “I’ve noticed that not everyone sees the issue in the same way. Could that help your process rather than hinder it? Cause that’s what it seems to be doing now.” Then, you can tell the team that you have an observation to make, and ask if they’d like to hear it.
If, by this point, the team can’t fix the problem on their own, you probably need to do more work.
The fourth thing you should try is to talk to everybody on the team individually. Ask them a set of neutral questions you can ask each of them. For example, “How well, in your opinion, is the team working together? What helps the team work well together? What keeps the team from working well together?” Assure everyone that you won’t tell anyone else what they’ve said unless they give you permission.
If you’ve tried all of these things and the problem persists, you may need to offer particular team members your observations about how they’re affecting the team. For example, saying to one person – in private, of course –, “I’ve noticed that whenever this particular team member says anything, you start talking before she’s finished.” Or, “I’ve observed that you use argument as a conversational style, but no one else on the team does. Other people don’t appear to like that.”
If, after you make observations to people individually, the team doesn’t resolve the problems, you may need to bring it up explicitly in a retrospective, and create a set of activities to specifically and concretely address the issue.
Of course, maybe one member of the team really is a problem. Maybe one person is causing trouble. If that’s what’s going on, talk to HR.
The next time you work with a team where one person seems to be causing trouble, before you think about who should take care of the problem, make sure you know what the problem really is. Observe the team, look for patterns, offer observations, and talk to people individually. Then create retrospective activities to surface the problem and deal with it explicitly.
Photo credit: © 2008 Lemsipmatt, CC BY-SA 2.0.