How to deal with difficult developer

Question

I would like to ask you for advice with my problem with one team member in an agile team.

Background

I'm the Scrum Master and team leader for a project for one of my company client's (a big corporation). My team consists of developers from the company I'm working at and the client's developers.

Problem

We have a problem with one of the client's developer, who is an old-school developer who has been working for the client for quite a long time. Both the team and I have a hard time persuading him to follow clean code and other software development practices that team agreed to do.

He has a background in a different technology stack (.NET, whereas we're using Java with quite modern frameworks in the project) and is trying to reinvent wheel every time. Every attempt to show him how something should be done in a simpler way ends up with a long emotional discussion (he behaves like he has been attacked).

He is also raising numerous ideas (including architectural) and tries to force them through. Unfortunately when it comes to validating, these ideas appear to be something that is against widely-used practices and patterns. For example, we have had a discussion why 100% code coverage is not a very good idea (he pressed to do that).

It has also happened that he was implementing changes out of the scope of his task. For example, he refactored some part of the application without consulting with the team, because he thought his code would be better. He tried to defend his code when the team tried to explain to him why that part of the code was implemented in that way.

My impression is that as he is the oldest developer with the most experience, he wants to be the project hero by all means. Unfortunately, he seems to be not up-to-date with modern frameworks and coding guidelines. I think one of the reasons for his behavior might also be a cultural factor (that guy is from the UK, some part of the team and I are from Eastern Europe). The problem is also that the client's management seems to not see the problem.

As I'm not very experienced in leading teams, I'm curious what could be the best way to fix team relations (two people already left because of that). I really appreciate the engagement of that developer, but would like him to be in-line with the team and look critically on his work.

Could you please advise what you would do in that situation?

(I know I can always quit my job, but that would be escaping the problem :))

Answer 1

Manage him out, sooner rather than later. The short term pain of his loss will lead the rest of the team to learn what the indispensable man knew and inspire fewer indispensable men in the future. See https://blogs.msdn.microsoft.com/eric_brechner/2018/02/01/good-engineers/

Answer 2

TLDR: Rather than treating him as a problem, one perspective is to view his actions as an opportunity to improve your process.

Code Reviews

he refactored some part of the application without consulting with the team

Why is a developer capable of a large-scale refactoring without the knowledge and consent of the Team? My suggestion is to implement mandatory code reviews (often accomplished via pull requests) on all accepted code. This is not just a benefit when dealing with this one developer. All code is improved by a second pair of eyes. It's also a good way to facilitate knowledge sharing.

Architecture Discussions

He is also raising numerous ideas (including architectural) and tries to force them through.

Personally, I'm not seeing the problem here. One of the things I learned from a Professor back in university that really stuck with me is the idea that "No topic should be taboo." In an ideal environment, any topic whatsoever should be able to be put on the table. Sufficiently bad ideas will soon enough, through discussion and investigation, be revealed to be such.

And there is always a chance that a seemingly bad idea only appears so because of pre-existing biases, and, when closely and rationally examined, holds up well. Furthermore, the very act of such scrutiny fosters a culture of learning. If one must be able to back up one's stances, then they must be thoroughly understood. This helps avoid cargo cults. New knowledge must be discovered to properly scrutinize ideas, and must be disseminated in order to reach consensus.

Rather than view such discussions as a threat, view them as a chance to learn, and to teach.

Unless you're on a strict deadline and one developer keeps trying to push through hour-long discussions involving the whole Team. Even then, though, you shouldn't just say "No, you're wrong", but rather "We don't have time to discuss right now. For now, we'll do X, and we can revisit next week."

Professional Detachment

Every attempt to show him how something should be done in a simpler way ends up with a long, emotional discussion (he behaves like he has been attacked).

One of the most valuable lessons any developer can learn is "I am not my code." An attack on code written by a developer should never be construed as an attack on the developer. It sounds like your 'problem' developer hasn't learned this yet. Have the other developers? Have you?

You should foster a safe environment where this kind of mindset is encouraged. Various ways to do this, but one of the most effective is by example. Ask someone else to review your code. Have them point out all the defects. Then simply fix them, in good humour, without getting defensive. Thank your reviewer for anything new you learn during the process. Encourage other developers to do the same. Eventually, your business's culture will evolve into one where this is the expected norm.

This is, of course, complicated by the fact that he's not your company's employee. That doesn't change the goal of creating an environment where developers feel they are safe from being negatively affected by a bad code review, though.

Answer 3

In your OP, you have some biases at play here that I think you need to take a look at. I have no idea how these biases are playing into your observations but I do know they are, simply because our biases always play into the situation and you were very kind to expose them: age, culture.

Secondly, you introduced him as a client developer. So this is not a person whom you "control" vis-a-vis as a PM. Instead, he is a client stakeholder. Which means you have to treat him like a client stakeholder, with both favorable and unfavorable impacts on your scope, your costs, and your schedule.

This is stakeholder management 101. How is he involved? What are his tasks? What information do you need from him? What information does he need from you? What project risks are caused by him and what actions do I need to mitigate them? And so on. You're not going to get him out of the sandbox so you need to figure out how to play with him. There are no easy answers here but the first thing I would do is bring him in as a partner. Get him involved, part of the discussion, and diffuse the likely alienation he is feeling and to which he is responding. It's manipulation but you can build favorable outcomes from it versus trying to fight it.

Answer 4

Dealt with these types of developers before and they are always a nightmare to work with for the reasons you are experiencing. What has worked for me in the past:

1) Keep a RAID log where all project related risks are logged. This will act as an audit trail. 2) Every time a risk or issue occurs due to x character, escalate to senior management by showing them the RAID log and how it has impacted the RAG status of the project.

As a Scrum Master you cannot get this person fired since you are not managing people but supporting the team, at best you can make management aware of the disruption x person is causing. They will then handle individual accordingly.

Answer 5

Sounds like this is really burdening the team and should be solved as soon as possible so that you can focus on the important things. Your developer sounds motivated in the end and that's a very good thing in my opinion.

In general every developer should be treated the same and I would not make any exception as a scrum master, be it your special developer or any other person in the team. The team should properly define a working agreement together and in the worst case you get to a decision via a majority in the team. People need to understand why the team wants to work the way they want to.

Maybe your developer does not use the latest and greatest stuff thats out there, but if he has a lot of experience he might be able to either persaude you not to rebuild and rethink everything because it is new, or he might see the benefits and stick to it.

Answer 6

I'm saddened to see all the responses suggesting some easy exit or simple solution involving some part of continued stifling of the team member. As previously stated, you must get those working agreements authored and committed to by the entire team via ceremonies intended to generate the agreements.

From there using your Agile Practices, it's critical to setup the team culture to promote team members holding one another accountable for their actions and deliverables. When this is done successfully, I have yet to encounter a team challenge that these broad approaches can resolve, explicitly in the case you presented.

Answer 7

Try managing him by objectives - or every sprint the team has targets. Since he is senior most (oldest) developer on the team ask him to make sure that the targets are met.

I my organisation I have power to move developers who are pain for the team. I usually create shadow resources and anybody who tries to show bad attitude or be hindrance in the project activities I replace them. I try to warn them or try to explain why the framework is important and if I don't see any improvement I replace them.

Sometimes telling them that if they keep on being difficult you will give lower rating or fire them, will set the attitude right.