How to Deal With a Problem Team Member

One of my very earliest coaching experiences was at Capital One and, in 2005, I had the opportunity to learn how to deal with a problem team member.

I had brought on as subcontractors a couple of trusted colleagues to assist me at Capital One. One of them was Deborah Hartman. She was working with this one team over a period of a few months as their Agile coach.

The team was having pretty serious morale problems and she had tried a lot of different things to figure out what was going on. But she hadn’t been able to get to the root of it. She naturally started to worry that maybe it was her; maybe she just wasn’t a good fit with the team.

So, she asked me to come in as a substitute coach and run a retrospective to see if maybe the team would say something like “Deb sucks.” And so I did. I came in and did a very simple retrospective that is a variation on pluses and deltas.

Fact Finding

Each individual gets six blank note cards:

• Three of them are used for pluses; things that went well.
• Three of them are used for deltas, or negatives; things they would want to see changed.

You do not put your name on the card when you write stuff. It’s strictly anonymous.

As a facilitator, you collect all the cards, shuffle them up so that there’s no particular order and you just read them out. But of course, you don’t show them to others because sometimes, people on a team will recognize each other’s handwriting.

So, I’m reading these cards out and the first few are what I think of as typical retrospective comments: “Our communication was good,” or “we solved that technical problem,” or “the space layout sucked.” Let’s call them the “safe” comments; easy-to-make observations.

Identifying the Problem Team Member

But then I read one which said “Jorge (not his real name) tells jokes that are completely inappropriate.” And then I read another one: “Jorge’s jokes are racist and sexist.” And then another: “I find these stories told by Jorge completely distracting and inappropriate.”

Every other team member had written a card about Jorge. Jorge was the problem team member.  And Jorge was sitting there with his team, hearing these really negative comments about him read aloud. You can imagine he was just turning bright red, completely put under the microscope. And by now, I’m feeling pretty uncomfortable too, by the way.

But after I finished reading them all out, this guy Jorge stands up and basically says “I’m so sorry. I had no idea. I really really want to be part of this team. I’m going to try and change. Please help me.”

It was very direct and obviously very sincere.

Change Happens

And that was it. It had nothing to do with Deb. It was an actual member of the team. And once it was out in the open, almost immediately the feeling in the team completely changed. This guy did indeed improve his behavior quickly and dramatically, and they went on to actually be one of the amazing early Agile teams in the organization.

Now, in many organizations, how would this situation normally play out? Well at some point, someone would complain to a manager or to HR about the problem team member. “Jorge” would have been called into an office somewhere to be berated, told “all your behavior is unacceptable,” and maybe even suspended, or worse, fired.

There would have been no opportunity for improvement.

Now, just to be clear: I’m not suggesting that you tolerate abuse. If he hadn’t changed, definitely escalate it quickly. That behavior has no place in in a work environment, or any environment for that matter.

What I am saying is that in Scrum, we give people an opportunity for improvement. We make sure that we create transparency that gives them that opportunity.

But he stopped as soon as he was made aware of it. And unfortunately, some people for whatever reason—family, culture—are ignorant of some of these things that make others uncomfortable. Let’s make them aware, give them that opportunity and then move on.

I also want to say that I was lucky. It wasn’t by some magic that my personality resolved this situation. It was simply the right technique, the right timing and the right group. It could have also gone badly.

Provide the Opportunity for the Problem Team Member

The intention of the retrospective is to provide the opportunity. Even if it doesn’t go well, at least the opportunity was there. And by the way, those cards with all the negative comments about Jorge written on them—they were all shredded. There was no record of that. The retrospective is private for the Scrum team.

You should never take minutes in a retrospective. You should never share the results of a retrospective unless the team unanimously agrees to sharing a specific item.

And a manager should never ask a team to share its retrospective results. Because guess what’s going to happen: the team is going to completely shut up and they’re not going to talk about anything at all. And then it’s not going to go anywhere.

—

This article was adapted from a transcript of a recent Certified ScrumMaster class that Mishkin taught in Toronto.

If you found this useful, please consider contributing with our
“Value for Value” model.