I am the Scrum Master of a development team of about 4 people. The role is not a pure Scrum Mater role but rather it encompasses Scrum Master, Leader of the Team and being a proxy for their line manager (who we all report too).

The line manager's expectation of me is that I am accountable for the effectiveness of the team. If the team does not deliver effectively, then it is considered to be an issue I must resolve. The line manager would help me though in any way he can to resolve the issue, if he agrees.

For example, I could initiate a performance appraisal process of one of the developers, but me and my line manager would do it together if he agrees. I suspect he does not agree with the following challenge:

One of the developers in my team has been struggling to deliver and contribute to the team. I did not come to this conclusion myself, the PO of the team also saw this and other developers came to me to say that he has only done 4 user stories in 1 year. Also he is painfully shy and introverted and never ever speaks in any workshop - so his contribution even to the team culture is zero.

I initially sent him to do some training and I also encouraged him to do more pair programming which he did begrudgingly. Later, I confronted the developer and said that he seems to be struggling and that he perhaps does not understand his role. I was very stern but I believe very fair. I told him that he is focusing on a lot of topics outside of the team but I don't see his contribution to the team.

Later I found out that he went on a campaign telling all my leadership peers, my managers and colleagues and other developers that I have created an unsafe environment in the team and he does not feel psychologically safe. I think it has had quite a big impact on my reputation.

My manager then said I need to work on building a relationship with him but does not really seem to agree about the low performance of the developer because I have mentioned it several times but he goes back to me building good relationships.

The developer and I had many discussions and I think we have made peace now about the initial issue and moved past that. However we obviously don't have a close relationship and he mostly does not engage with me unless he has too.

I am in a difficult position now because he has tarnished my reputation which I built over 5 years so surprisingly quickly and also at the same time the problem still remains that his performance is sub-par.

I think he has become very close with the rest of the team so I feel a bit unsure how to proceed. The team does not seem to care about his low performance now and also outside the team no one seems to care however I am getting battered by management that the team as a whole is effective.

The only options I really see are:

  1. Resigning
  2. Moving to another department
  3. Putting the developer in a performance management process but it would ruin what is left of my reputation
  4. Just leaving him and hope the rest of the team can pick up the slack

Does anyone have any other ideas?

  • 12
    How can he contribute nothing to the team culture yet be very close with the rest of the team? Is it possible that he's having interactions with the other team members without you present, and simply avoids talking in environments that you're in? Commented Jul 17, 2023 at 16:04
  • 2
    Know precisely what has and hasn't been delegated to you. If it's something you haven't explicitly discussed with your manager, ask before assuming you have that authority and ask how best to exercise it. And if you do guess, and guess wrong, immediately accept the correction, apologize, and learn from it.
    – keshlam
    Commented Jul 18, 2023 at 5:26
  • 2
    And even if you were w full manager, there are good and bad ways of doing that job, and focusing on blame rather than gently trying to help the individual improve is generally one of the bad ones. Which goes back to "ask how to do it right."
    – keshlam
    Commented Jul 18, 2023 at 5:39
  • 2
    Only do performance reviews in a formalized matter if you a) do it for everybody or b) try to fire somebody or c) maybe with a unfounded overly confident employees it can be a tool to get them in line. But with shy and introvert employees this is only going to make matters worse. You have to build them up not threaten them.
    – seg
    Commented Jul 18, 2023 at 6:59
  • 2
    Are you a Scrum Master, or a "proxy Line Manager"? At the moment, title and body disagree. I'd suggest putting back Scrum Master in the title, as the edits that led to "proxy Line Manager" vastly affect the responses, and questions should not be changed substantially after being asked -- new, different questions should be asked instead if necessary. Commented Jul 18, 2023 at 8:40

6 Answers 6


But I think it’s a tricky path and you have made 2 mistakes:

  1. you assumed that an employee performing poorly was something your company cared about.
  2. You didn’t consult managers/superiors before you took action

  I feel like 1, who could blame you, but you do see it a lot in IT, that there are some people that seem incredibly unproductive next to high performer tech people. I typically don’t have a great answer for that, there are a few strategies which can work, probably the best one being that you keep moving that person around, assigning them different types of work, and then hopefully something which provides value to the team. Something with low technical difficulty (could be testing work, monitoring work, auditing) Something repetitive in nature, that is not challenging. A high performer would be bored with this task, but this employee will have rather feel comfort as they know they can do their job week to week, and won’t go a year with only 4 stories etc.

  But what is the bigger mistake is not strategizing/consulting/discussing with your managers about your poor-performing team member. When warning somebody about their performance, you may need to have documented months of their behaviour, previous communication you’ve had with them, etc. This is not something you can do on a whim, or unilaterally. Management would need to be in agreement, you would have had numerous conversations, and you would discuss every step you would take before you took it with management. Even if you didn’t see this as a formal warning about performance, it can be construed as much.

I would challenge that you have completely tarnished your reputation there. If you look at what didn’t work in this instance, do the opposite. Consult with management how to align back with their expectations, strategize how you can get whatever value out of this person you can, how you can repair the relation ship, coffee+supportive conversation that you believe they have unique abilities, and maybe you haven’t been taking advantage of them as best as you could have, and you want their support to do so, even if this isn’t accurate in your opinion it’s simply a different way to use language to get them on side. Then sell this as a win back to management, and moving forward you will operate in a more team based manner.


Scrum Masters don't manage performance

While soft skills are important in this role, these soft skills should be focused on helping people succeed, not being "stern but fair." Stern but fair is for the person's manager. The scrum master owns the process. Managers set expectations and hold people accountable for results.

So now we need to answer how legit the developer's complaints were. There's no way to know this, but apparently your hierarchy (and direct manager) seems to think the complaints had merit.

So where to go from here? It's hard to say. You need to balance your current situation with the unknown of a new one. If the complaints did have merit you may find similar complaints difficult to overcome in a new workplace. Regardless, you need to relax your expectations of managing the performance of someone their manager isn't interested in managing. Take their schedule input and manage appropriately. Consistently assigning more work to them than they will get done is a management problem as much as a problem with their output.

Subject to comments, I will add the following: The Role of Scrum Master is not a role that manages performance. Certainly an individual can hold multiple roles. The Scrum Master could be also the Project Manager, the Direct Manager of the team, or could hold any other role(s) that exist in the organization. Those roles would specify who is responsible for the performance of team members. The Scrum Master role should not be the role expected to do this.

Edit again due to changes on the question from "Scrum Master to "Proxy Manager." If performance should be managed together then manage performance together. Do it on your own at your own risk.

  • 5
    @JoeStrazzere I agree with you, but a company trying to make a Scrum Master manage the performance of the team members is making a huge mistake.
    – Tiger Guy
    Commented Jul 14, 2023 at 20:27
  • 5
    @TomTom any company who thinks managing performance should be "dumped" on people deserves what they get, large or small. People need bosses in any sized company.
    – Tiger Guy
    Commented Jul 14, 2023 at 21:04
  • 13
    Well, we arrive at the usual conclusion: anybody can call themselves the "Democratic People's Republic", but you have decide if they actually told the truth and whether it's worth living there. I could put "catching and butchering rats in the alleyway" in a job description for Scrum Master. Doesn't mean good Scrum Masters should start working there, because someone was able to type "Scrum Master" into the template.
    – nvoigt
    Commented Jul 15, 2023 at 10:54
  • 4
    It isn't uncommon for a manager to act as scrum master. It isn't common for a scrum master to thereby acquire management responsibilities or authority. If they want you to manage, as opposed to being tech lead, get that in writing and preferably get a raise.
    – keshlam
    Commented Jul 17, 2023 at 1:45
  • 3
    @keshlam - a scrum master isn't a tech lead either... (although the tech lead can often be acting as the scrum master in the same way as a manager can) Commented Jul 17, 2023 at 14:20

Later, I confronted the developer and said that he seems to be struggling and that he perhaps does not understand his role. I was very stern but I believe very fair

This is where you went wrong; everything after that is follow on.

You should have either looked at a PIP or talked to whoever has the authority to do so. Be professional, don't confront people without the authority to just enforce if need be. You don't give problems a chance to escalate beyond your control.

Once they do then it can start looking bad really fast, because busy, uninformed people have to look at it and cover their own and the company's back.

I've seen plenty of incompetent or worse people. I don't confront them. I stick to my role and just professionally pass discipline to those whose role it is. I give a professional heads up sometimes, but that's all.

  • 3
    I don’t think I fully get what you are saying. Are you saying I must tell people who have the authority to deal with the developer about his performance but not deal with it myself?
    – user32613
    Commented Jul 15, 2023 at 12:10
  • 42
    Yes, if you don't have the authority then it isn't your problem, just professionally pass it to whoever gets paid to deal with it. Any persistent problem you can't easily fix within your role should be passed on.
    – Kilisi
    Commented Jul 15, 2023 at 12:14
  • 8
    @user32613 if an electrical outlet in your office doesn't function correctly you don't try to fix it yourself (that's how office fires start) - you inform someone whose job it is to fix electrics in your office. And until it is fixed you try to work safely around the issue.
    – Falco
    Commented Jul 17, 2023 at 10:31
  • 1
    @Falco That's actually how people die. You need some type of major failure for fires, since a straight-up short circuit is supposed to blow the fuse, but you'll die before that happens.
    – Nelson
    Commented Jul 18, 2023 at 8:01

I think that you've pretty much covered your options. There is some nuance to them though, to which I can make recommendations:

  1. If you resign, don't mention the employee, or your perception of your reputation, etc. Just say you wanted to move on to new work, you enjoyed your time with the team and the company, and wish them the best.
  2. If you move to another department, same as #1.
  3. If you can justify a performance improvement process with solid numbers such as user stories done per month, then this could be viable. That said, if your management has already said they don't care about the employee's performance, then it will be difficult to justify. If you go this route, I would recommend trying to do as much pair programming and mentoring as possible (and documenting it) in the weeks leading up to it to show that you've made a genuine effort before resorting to this.
    • Careful about this though - there are variety of reasons why your management has been so resistant to taking action against this employee. It could be that the employee is a friend or relative of someone higher up, or they fear that the same reputation assassination that was done against you would be done against them and/or the company. You'll have to do your research and talk to management to find out for sure.
  4. \(:|)/ Sometimes you have to just let it be. If the employee has a positive relationship with your team, and your managers aren't putting pressure on you to improve their performance, then why put your neck on the line to fix a problem that doesn't exist?
    • In the meantime, you can focus on rebuilding your reputation, and making sure that the shortcomings of the employee are as visible as possible - for example, adding a breakdown of each of your team member's user stories completed each quarter when you submit reviews or data to your management. If they see that everyone on your team did 5 user stories in a quarter, and one person only did 1, they will take notice. Eventually, this could set you up better to try to do #3, or even lead to someone above you taking initiative in dealing with the employee instead.
  • 6
    @TomTom, there is a vast space out there consisting of managers who have very little ability to fire people for merely poor performance comparative to others. In other words, their role as managers is to coordinate work, make best use of their allocated resources, and use good judgment to ensure that work embarked upon is within the reasonable capability of their team - not to simply seek a preferential selection of staff.
    – Steve
    Commented Jul 14, 2023 at 21:06
  • 7
    @TomTom Are you aware that a Scrum Masters job is not to "run a team as they see fit", but to make the best out of the team they have? I mean you can quit if you don't get your dream team, but you surely misunderstood the job description of a Scrum Master then.
    – nvoigt
    Commented Jul 15, 2023 at 5:30
  • 2
    @nvoigt yes I believe this is the core of the problem. The team cannot trust me as a scrum master because technically I can also make performance processes happen. So I am kind of in this no man’s land of a scrum master with a little bit of authority but not enough to be called a manager.
    – user32613
    Commented Jul 15, 2023 at 12:17
  • 12
    Measuring individual developers by their completed stories is extremely toxic. In a good team, more senior people mentor more junior ones, and everybody puts reviewing merge requests before starting new stories ("stop starting, start finishing"). I've also seen examples where software engineers (... very good ones ..) got stuck with some third level support because they did understand the system best, and adding a dedicated support specialist to the team was not cost-effective.
    – o.m.
    Commented Jul 15, 2023 at 16:49
  • 1
    @o.m. OP never said if the developer was junior or senior. But regardless, what's wrong with measuring by story points? It represents a number of meaningful units of work, and it's something that management can understand. I understand why people dislike many metrics of programming, lines of code for example, but eventually management needs to be able to put a number to the value someone is generating. Certainly in the contracting world that's the standard for doing so when writing reports to the client. Commented Jul 17, 2023 at 14:20

I'd bring this up at the next team's retrospective. Talk about it as a team, get how everybody else sees the problem, and then have the team come up with an attempt to solve it. As scrum master, you're not there to solve all problems for the team, you're there to help the team solve its problems.

If you are not yet doing retrospectives, it's about time you start to. You're much more helpful as a scrum master by showing the team the tools and mechanics scrum has, than by trying to be a manager.

  • 1
    The colleague was complaining about perceiving an "unsafe environment." Imagine if said person was singled out in a retrospective and everyone was supposed to give feedback on this person's poor performance. That is straight up bullying. Commented Jul 18, 2023 at 7:39
  • @user3819867 I didn't say anything about singling out someone, but if the team cannot discuss such issues or if something cannot be discussed because someone feels uncomfortable about it, the team is doomed anyway. Retros are also not about giving feedback on performance, they are about surfacing problems and the whole team takes a stab at solving them.
    – Robert
    Commented Jul 18, 2023 at 18:54
  • How would you discuss a single individual's performance issues (including possibly putting the person on PIP) in a circle with their peers without it feeling like singling them out? Commented Jul 19, 2023 at 6:38
  • @user3819867 I don't want to discuss individual's performance in a retro; I want the team to say what went well and what didn't. And if one of the items in the "what didn't go well" column is "we didn't get many features done", then the team can discuss why that was the case and what to do about it. Maybe pairing helps, maybe tasks are unclear, maybe that person has too many other things on their plate. But it needs to be discussed, as it affects the whole team. Part of a scrum master's job is to have retros and make problems visible.
    – Robert
    Commented Jul 19, 2023 at 14:01
  • The question was about one person's performance bringing down the team even after specific trainings and pair programming, then accusing the OP of creating a hostile environment. Your answer does not seem to relate to that. Commented Jul 20, 2023 at 8:42

[I am] Scrum Master, Leader of the Team and being a proxy for their line manager

There is the error. These three roles are not necessarily compatible, and the latter two do not even exist in a Scrum context, formally speaking.

In business, "roles" are a very important construct. There are certain expectations or responsibilities for each role, and it is important that the people who have a role actually prioritize those responsibilities.

The responsibility of a Scrum Master is to make the Scrum process run smoothly, with a focus on enabling the team. I.e., in a new team, the Scrum Master would introduce all the artifacts (dailies, plannings etc.) and moderate them, at least in the beginning, at least until it is not necessary anymore. The Scrum Master would also wield the Scrum process as protection for the team in case a Stakeholder tries to overstep the boundaries and, for example, tries to make the team take on additional stories mid-sprint.

A "Leader of the Team" does not exist in Scrum parlance, nor in any Agile mindset I have come in contact with. Teams are supposed to self-organize (with guidance and within the boundaries set by reality, of course). You might have a very experienced person in a Scrum Team (i.e. a senior architect familiar with the domain and technology) or something like that, but you would never want them to be perceived as a "Leader". They could do many things within the team that might have been done by a "Leader" in the distant past, but must not view themselves as such.

A "Line Manager" is something which is not mentioned by Scrum at all and has no place in the process, whatsoever. In reality, they must still exist, of course - this is part of the "boundaries of reality" mentioned above. The responsibility of a Line Manager depends a lot on company culture; in my company their main responsibility is to enable their employees to work as well as possible in their projects, to protect their employees from anything untoward (for example: old-fashioned project leads, whose responsibility is the success of their project, not the well-begin of the employees), and handle all the real-world problems that occur outside of actual IT work (i.e., salaries, vacations, etc.).

The role of the Line Manager is often fraught with the (real or perceived) power they wield over the employees, mostly over salary and benefits, and their possible involvement in disciplinary actions if those ever should become necessary. Hence it can work great to be in a project together with your Line Manager, but it can also be a great idea to avoid that.

So in short - your three roles run high risk of being not very compatible. You will have situations (like the current one) where your roles tell you to do different things, and throw you into a conflict that is almost impossible to untangle. In the future, try to have at most one role at a time, or at least roles that do not conflict with each other (for example, in my experience, it's fine to have the role of Line Manager for one team, and Senior Developer or Scrum Master in a different project team, with no overlap of employees - this helps to pay the bills unless your line team is so big that it takes up your whole time).

In your current position, I'd sit back, relax, let him do his thing, let the team pick up the slack, and try to get back to normal. Take care of your own mental health first, reduce your own stress. It seems clear that you cannot really influence the things you are trying to. Be in tight communications with your own manager, and let him help you wherever you can.

  • The roles are not completely incompatible. I've worked with many managers who were fine (if not excellent) scrum masters But that's like saying I've worked with many managers who were excellent engineers -- it's two different skills, and while each can inform the other they are different responsibilities, and use different tools.
    – keshlam
    Commented Jul 18, 2023 at 12:32
  • 1
    Yes @keshlam, I happen to work in those two roles as well, but I make sure (from experience) that the overlap between line mgmt and project stuff is minimal.
    – AnoE
    Commented Jul 18, 2023 at 12:53
  • Just quibbling with the one word. "Absolutes are always inherently false." <grin/>
    – keshlam
    Commented Jul 18, 2023 at 13:02
  • 1
    Fair enough, @keshlam, I have defused the relevant sentences to make them sound less absolute.
    – AnoE
    Commented Jul 18, 2023 at 14:07

Not the answer you're looking for? Browse other questions tagged .