what to do when one team member doesn't value collaboration?

Question

I've just finished running a retrospective of a team I doesn't manage usually (they don't have a dedicated ScrumMaster), and it appears that there is a conflict of opinions in the team (which is relativelly small in members).

The majority of the team rate themselve as doing poor in term of synergy and collaboration. They think it's their main weakness and think they should take actions on that.

But on the other side, one of the member think they are fine in this regard and this is not an important aspect to be taken into account for the overall team performance. He says communication is fine, that they talk enough already and that bug tracker is sufficient. He says he perform better working alone and that disruption from more collaboration would deteriorate his productivity.

It's obvious to me that the synergy of this team is indeed bad, and this case is an obvious example. So I'd like to address that without hurting the feelings of anyone. But during the retro I couldn't come up with a quick and elegant solution.

Any advice on how to solve such a case?

Answer 1

As the saying goes, your team is as strong as your weakest link. A high performing team is about collaboration and communication and a sense of collective success and failure. And an individual who "prefers to work alone" can disrupt that process and inhibit that teaming dynamic you want.

HOWEVER, leaders of teams also know that the team is made up of individuals, each of whom has unique personality attributes. Some personality types are simply more conducive to 'working alone' than on a team. And there are specific team roles where this type of personality is a FAVORABLE CONTRIBUTOR to the team and the teaming process. Said another way, if you examine each type of role (use Belbin's definitions as an example) each role brings with it a set of strengths and a set of weaknesses. This is the challenge, to exploit the strengths you want while 'paying for it' with acceptable weaknesses.

So it can be too myopic to assume this person is a team poison! It might be that this person does not want to collaborate in the manner in which YOU define collaboration; however, if he fulfills a team role where his personality is a fit, then by definition he is collaborating to the benifit of the team, despite how it looks on the surface.

SO BE VERY CAREFUL HOW YOU LABEL THIS PERSON'S BEHAVIOR!

Some possible roles this type my fit: specialist, evaluator, investigator.

Answer 2

• Retrospective is a dangerous place for discussing team collaboration. A one-to-one meeting is a better alternative for addressing this specific issue.
• Somebody's feelings will be hurt. Ideally, their professional work ethic will make it easier for them to improve and move on.
• Assuming you are correct, you need to establish why this hasn't been brought up before. Their manager (SCRUM master) might well be responsible for this.
• Some people are rather influential as well as destructive. These people are capable of causing great damage to the department. Identify them early and ensure that you either keep them happy or make them redundant.
• It's risky to make a decision based on an outcome of a single retrospective. Gut feeling is normally correct, but it's by no means enough to make a decision.
• Just because there are more people that agree on X, doesn't mean that they are correct. I have previously worked in a team where less experienced developers blamed lack of collaboration, when it wasn't a problem.
• Regardless of whether majority or the minority are right, you'll have to overrule one of the sides. If one of the side fails to accept their loss, then further actions should be taken. Otherwise it'll have a negative impact on entire team.

Answer 3

Unfortunately, I see this scenario more often nowadays. My friend had the very same issue last week, although he hasn't done anything with it yet. I asked around and talked to several successful team leaders and this is the common way to handle situations like this:

1. Ask the person to join you for a face to face conversation immediately. Share your observation with him and tell him about the values of the company and the values which are required now. So, start from your personal view, move to the company's view afterwards. After that, he can share his vision and try to find out why he doesn't value the same things that you are doing, and what is motivating him.
2. Let's say find the reason why he behaves like this and offer your help so that he can start changing. Don't make it optional. You need him to change, and you need it now. Help him as much as you can. Have a deadline, and have the same conversation again and see what has changed.
3. If you don't see a chance to find his motivation and he still behaves like before after your meeting, then get rid of him.

A personal story. I had a developer who wasn't contributing as much as he could do and he really slowed us down. We had the face to face discussion where I told him my observations - I was really gentle - and asked for his view. We agreed that is a problem and he wanted to change. I told him that I was here to help him, but if nothing was going to happen in a month, I would find a new team for him. It helped, because I was told that he is in the top 5 at the moment. He needed a wake-up call, some help and a consequence.

My rule of thumb: I value teams more than individuals. Everybody is replaceable. I don't let a person poison my team, even if he is the best programmer you can find on the market.

Answer 4

I know my answer is even later... but I'll add it here in case somebody else arrives at this thread from a search.

There's a few other things that people in this situation might want to consider.

1. What stage of the group development are they in (Bruce Tuckman), Forming, Storming, Norming, Performing? Quite possibly they could be in the 'storming' stage where team members are finding their position in the team, were they lay in the perceived pecking order. Even though there won't be a real pecking order and all members should be equal, there will be a bit of jostling for positions and to appear to be the most knowledgeable. There are ways of dealing with this and it's always worth listening to concerns. The storming is important, get through that and you're well on your way to full performing!

2. As mentioned in a comment, this team has long dailies, extensive brain storming, lots of pair programming which makes me wonder if this scrum master has it right. Are they using tools for the sake of using them and not because they're effective. Possibly this team members has noticed that and isn't happy with how the team is performing because of it. Remember, job satisfaction is often more important that salary, especially where developers are concerned.

It's sad that people have jumped immediately on planning this team member's exit just because he doesn't agree with everybody else. Has anybody thought that he might be the only one who is right. I had guy like this once and rather than tossing him out the window, I kept hold of him and used him as a check-and-balance, knowing he was going to questions my every move and run to the boss really kept me on top of my game and, much to his annoyance, made me perform even better as his manager!

I could go on, but I'll stop here...

Answer 5

I know my answer is late, but some of the back and forth made me want to add a new comments.

1. During the retros do you not only identify issues but also come with Action Items or something to try just for the next sprint. This is a good way to let people with differing opinions try something out and then talk about how it did or didn't work. If they aren't running a facilitated retro, here is a quick guide for one. Retro How To

2. I would also run some team building exercises. Is this really a "team" OR just a group of people assigned to the same project. Often these are confused. There is no quick fix for building a team, but you can start by looking at some coaching exercises or other visualizations or good old fashioned lunches together.

3. Get this team a Scrum Master. It seems like in a later comment that you identified a lot of the "issues", but there is no one there to support the team in "how" they work. Get them a coach to help them through the game.