How to handle scrum team member that is never at his desk

Question

I am a scrum master for a team of developers and testers. One of the developers is never at his desk. He spends maybe an hour or two hours at his desk while the rest of the team are at their desks usual times. Of course they have breaks and lunch etc but usual times.

There is no team lead or anything like that for the team.

He is not attending meetings or training when he is not at his desk, he is usually visiting friends in the company or outside smoking.

Does anyone have suggestions for a how I, as a Scrum Master can handle this situation?

Update: I meant they are not away from desk due to training or other meetings.

Answer 1

As the Scrum Master, you should not be handling this situation. You should be coaching and facilitating the Development Team to solve this problem, and removing any impediments to their ability to solve this problem.

First - does the Development Team consider this a problem? If not, there is nothing to do. If it is a problem, the Development Team should have an open and honest discussion about the problem at a Sprint Retrospective to try to come to solutions.

The Scrum team should embrace the concepts of courage, openness, and respect. If one or more people have a concern about the way the team or a member of the team is working, there should be open communication among the team members and everyone should respect their thoughts and opinions.

Second - become a coach to the individual. It may be OK that he is not at his desk, if he is contributing work. However, if he's missing Scrum ceremonies (such as the Sprint Planning, the Daily Scrum, the Sprint Review, or the Sprint Retrospective) or not completing work from the Sprint Backlog, then he's hurting the whole team. Try to understand why he's not participating and explain the importance of being there and engaging with the rest of the team.

Every individual on a Scrum team should demonstrate, among others, the Scrum values of commitment to the team and effort, focus on the goals and objectives, and respect for the rest of the team and for stakeholders.

Ideally, the problem should be solved within the Development Team. However, this isn't always possible. If you need to go outside the team, you can, and as Scrum Master, you should be the facilitating this. You can involve the individual's direct supervisor or HR, as appropriate for your organization. But your first step should be to help coach the team on how to resolve interpersonal conflicts between members.

Answer 2

He is usually visiting friends in the company or outside smoking.

I don't think it's your personal responsibility to talk to that guy about it, as long as he attends the mandatory meetings and follows the Scrum process. It is your responsibility to support the development team to talk about improvements in the retrospective though.

In the retrospective, I don't think it's very productive to talk about this in abstract terms. If you tell somebody that in theory, if they were at their desk more, they could get more work done, all they have to do to prove you wrong is to sit at their desk and be even lazier than the sprint before. Next sprint, your argument has been disproven and you are even worse off than before.

There are at least two very real problems that pop up. We used those two to focus on real issues to fix. It's a little bit like Stack Exchange: you need a real problem to get a real solution.

The first problem we had as a team was that people would come by and ask for him and we had no idea where he was or when he'd be back. That made us look stupid, like we did not know what the other people on the team do. So we brought that up, we said "Hey, listen, when people come in and ask for you and we don't know where you are or how long you'll be gone, that makes us look really bad, like we are not a team or don't care. How can we fix that?" We agreed that anybody leaving the room for more than a short toilet or coffee break would simply say where they went. "Hey team, Bob from Beta Team called, he needs help with a database problem, I'll be downstairs for a while." Should be enough. No red tape, no procedure or system, just plain communication. That fixed a real problem for us and it raised the awareness for people not being "there". Nobody objected.

The second real problem we had was too many tasks outside the team. That's more of a PO's problem, because inside the organisation he got the budget for a X people team, but only (X-?) people work on his tasks, with ? people working basically on tasks of other teams. We fixed that by using more transparency, posting a little post-it to a wall with a note saying what we did and for how long. After a sprint we would collect them and decide what to do about it. Maybe other teams need education, maybe we are missing a task in our team or maybe somebody needs to be told "no" once in a while. Whatever the solution is, make sure people write down what they do for others. That guy that is constantly away should produce a lot of those. Remind him if he forgets. Work on reducing that number of "out-of-scope" work. Don't target him specifically, target the problem: work done for others.

So to summarize: the team should improve and go tackle the real problems that exist. The person in question is a part of the team and should have a say in this. This is not about him, or his behavior, it's about solving the problems. His absence will sooner or later be reduced automatically when the problems get solved. Your job as a Scrum Master is to help the team do that.

Answer 3

You have an employee that appears not to be doing work. You describe only the optics of his performance but make no mention of measurable output. Appearance of busy can be deceiving. And making it an expectation to look busy will get you just that but does not necessarily mean more production or better production. And doing so could also jeopardize an employee's feeling of professionalism, independence, mastery, etc., which could then jeopardize morale and then productivity.

Furthermore, you, like the rest of us, are biased and your observations of this person's behavior could be the output of a biased assessment. In other words, you expect this guy not to be at his desk and make notice when he is not as his desk and ignore or dismiss when he is at his desk. The question becomes, is he really away from his desk significantly more than others?

So before doing any coaching or behavior changing or whatever else, take a look at output, at assigned tasks finished on time, quality of performance, etc. Then, if those metrics truly show a gap between him and others, then you have concrete objectives for him to close...which will NOT include sitting at your desk. And then if after a reasonable period of time he does not close those gaps, then replace due to cause.

If it turns out his productivity is the same or better, then you a bunch of developers not pulling their weight...a bigger problem.

Answer 4

As a Scrum Master the first thing I would try to understand is the motivation for this behaviour. Why do they not want to spend time at their desk?

Secondly I would focus on the problems caused by the behaviour, not the behaviour itself. If they behave like this but the team is still highly productive then there is no issue. However, perhaps there are problems such as:

• Delays when team members are waiting for this individual to return to their desk
• Misunderstandings as the person was not available to answer questions

If these kinds of issues are happening, then they should be raised at the retrospective. Something like:

That last release was painful because we didn't realise the database hadn't been refreshed. Is there something we can do as a team to make this information more readily available?

By focusing on improvement you can make this a positive conversation rather than criticism of somebodies behaviour.

Answer 5

Assuming his output is appropriate (i.e. he's getting his work done in a sensible amount of time) and that the direct "come to a meeting" approach can't work, for whatever reason.

When why not approach him and ask him if he could join the more important meetings.

Maybe ask him what times work best for him.

At the very least, get his input to the meetings beforehand and appraise him of the results, decisions and action items afterwards. Best to do this verbally - emails are too easy to glance at and ignore.

Once he sees that he's anyways attending in absentia, maybe he'll decide to join.

The less time he saves by not coming (i.e. the longer your pre- and post-meetings are with him) the higher the chances of him attending.

(But make him feel that you enjoy those meetings with him; otherwise, he'll figure out that you'll give up before he does.)

Answer 6

Determine if you have a problem: If the team member's work is good then let it be.

Talk to the person: If there is a problem with quantity or quality of work then talk to the person with the aim of improving output. Discover what motivates them. Find out if they actually enjoy the work or if they would be happier in some other role. Ask questions to get to the root of what is happening in their work life.

Improve the situation: If appropriate pick out someone who does produce good work (maybe yourself) and use their behaviours as examples of good practice. Perhaps link the two together into some kind of mentoring relationship.

Answer 7

A Developer who has time to chat to friends and smoke outside is the ideal victim Team member to be first responder for unplanned work e.g.

• an urgent BAU item that must be done right now
• a Developer is blocked and would like to pair/swarm for a while
• the PO wants a status update

...or anything else that could distruct Team members who are actively working on the Increment.

However, if "is never at his desk" means this Developer is not available to the Team then his spare capacity cannot be used effectively or at all.

As others have pointed out, there may not be a problem here. I think we can draw a parallel with the PO; that is, the PO is normally physically absent from the Team for periods of time but if they are fulfilling their role (Scrum Events etc) and maintain reasonable availability to the Team to clarify, give feedback, etc then there should be few issues.

One positive aspect is it's (presumably) very apparent when this Developer is not actively working on the Increment. Their empty chair is very transparent to the Team. Personally, I favour sitting in the chair and putting my feet up on the desk when no one is giving me anything to do (when I rather think they should be), it sends a really clear message! As SM, I'd much rather see an empty chair than learn after the fact that a Developer had been sitting at their desk 'refining' items in the Product Backlog in isolation. I'd also ask questions to ensure everyone else in the Team was genuinely happy with the whole 'empty chair' thing.

Possible dysfunctions to reflect on:

• Team members failing holding each other to account.
• Individuals solving Impediments as they arise (rather than raising them to the Team).
• Impediments only being raised in Daily Scrum/Retro.
• I-shaped people (rather than T-Shaped people).
• Individuals working on tasks (rather than the Team working to deliver the Increment)
• Sprint Backlog Items being 'owned' by individuals (rather than the Team).
• Other Developers similarly have frequent 'slack' time but are not being transparent about it.