I am the ScrumMaster of an engineering team. My opinion is that 2 of the team members are not performing at a level which I would expect. This opinion is formed with the following information:

  • Daily stand-ups: they are generally not progressing through tasks and getting involved in sprint work like the others are.
  • They are very pessimistic and constantly telling the other team members that it will be impossible to deliver on their sprint commitments.
  • They truly find almost everything a joke and the constant failure to deliver on sprint commitments a failure
  • The other team members are active and productive, constantly raising their views, speaking up, picking up new work and keeping the team moving forward
  • They don't appear to be interacting, pairing and being productive for most of the day.

My question is, when (if ever) is it appropriate for a Scrum Master to bring these views to the attention of management or do I just continue trying to get the team to evolve and deal with this on their own?

  • Have you raised their poor performance with them directly? Has the rest of the team? – Erik Sep 28 at 16:29
  • "performing at a level which I would expect." means you have expectations of them -- are they aware of those expectations? – Robert Paulsen Sep 28 at 19:18
up vote -1 down vote accepted

As a Scrum Master, one of the main responsibilities is to identify and remove impediments in the team. Scrum masters don't manage people and their tasks. Need to coach and train people to become cross functional and truly agile.

Hope in the Standup, people answer the 3 Questions. If no impediments are reported, discuss with the two team members individually and find out what is stopping them from being productive and / or make progress in the assigned stories / tasks.

  1. If there are technical issues that they are not able to solve, pull other technical folks to pair with them and resolve. Need to stress to these two folks and also to the others that AGILE is all about team commitment.
  2. For personal issues, as a Senior folk help them out where you could motivate them.

Need more details on how many sprints the team have successfully completed on their committed stories and on the times they fell behind the target; reasons for that and the resources productivity in the previous sprints.

There are many factors to look into before raising flags against anyone. If you have supporting data, work with the resources and their managers and help each other.

It is appropriate for the Scrum Master to raise this issue with management only if they have been asked to do so by the team.

If you speak with management without first being asked to by the team then you run the risk of:

  • Being seen as a 'spy' for management in the team
  • Losing the trust of this particular team member and possibly other team members as well
  • Having management see you as a source of information on individual performance in the Scrum team

As a Scrum Master I would typically wait until this issue is raised at a retrospective. If the issue is never raised at a retrospective then I would ask myself:

  • Is this really a problem? Or am I just perceiving it as one?
  • Does the team feel confident enough to speak out about this kind of matter at retrospectives?

If the second option seemed most likely then I would speak with the team about the way self-organising teams solve their own problems and about how best to use retrospectives to do this.

Answering your question directly, the only acceptable reason to call out to management is when they are not performing as expected, but as it has been mentioned, they need to know very clearly what are the expectations. I personally prefer to do as much as possible to sort the issue with them/the team directly before involving management. I think you need to have an individual conversation with them. The best way to do this is by:

  • Setting yourself in a mindset of a resourceful and empathetic individual, make them feel that you really care about them and you are trying to understand what is going on
  • Expressing very concisely the behavior that you observe, but don’t “make the person a problem”. Talk about what you are observing. One way to do it is saying: “we are expecting that tasks get completed every sprint, how do you feel about your tasks? can you help me understand if there's anything getting in your way and how we can help you?” A one not recommended way would be to say: “You are not finishing your tasks and you are a very negative person”
  • Be incremental. Try to address one or two issues every time.
  • Make sure that it is very clear for them the ways of working and I would even create a team-wide document to explain behavioral patterns that are helpful to work in teams. They might not be completely aware of the "harm" they are causing.

Perhaps you should also get some clarity on what is the perception from other members of the team.

I suggest that you do the following:

"First, buy each one of them a cup of coffee." Separately. Frankly present each of them with the concerns that you've just raised here. Then, "shut up and listen." If necessary, clarify that you're not trying to "get them in trouble," but rather to better understand why their behavior is noticeably different and, in your view, working against the general progress of the team. No, they don't per se "work for you," as you should stress, but "the project, itself" is your delegated responsibility.

It is quite possible that you will discover something that will enable you to make the problem go away. It is also very likely that you will be surprised, and maybe, challenged (in a good way).

If not, it's time to have a private meeting with the responsible manager and to present the matter to him or her. Then, again, "shut up and listen." It is quite possible that you will be told something else that will make the problem go away. Or, you might hear something that relates to the approach that you are now taking.

"Have an open mind and, generally, a closed mouth." You are a professional, and your professional responsibility is to the project. You will now have solicited inputs, first from the team members whom you have singled out, then from the project's management. Carefully consider everything that you hear.

Any questions that you may have about how you should "act differently" going forward should first be presented to the manager for consideration.

  • First make sure they like coffee! Difficult though it may be to believe, there is a rare, elusive breed of engineer/programmer who do not possess a caffeine addiction. – Sarov Nov 16 at 14:10

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.