As a Scrum Master, how to speak to a developer about his delays?

Question

What would be the right approach to have as a Scrum Master to speak to a developer about him being late in the office everyday (we show up between 9:30 and 10 in the morning, it is not a clear rule but a kind of unofficial rule).

I am not the boss (and I do not want to be boss), but since 4 sprints now, we clearly see velocity going down, we have 3 developers, so if one of them started to be not engaged, it is impacting the whole team.

I know, developers tend to be more free and some of them prefer to come late and leave late, some of them like to work at night etc.. in our case, the person comes at 10:45 and leaves with us (in the best scenarios he leaves 15 minutes after us).

I DO NOT TRACK HIS MOVES, but I do track the sprint goals progressions, and what we all promised to deliver to our clients.

Some things to take into account:

• I am a new scrum master in this team (1½ months).
• This developer is leaving the company in 2 months, but we need to deliver work.

My first idea is to speak about that during the next retrospective and do it as a question, my objective will be to have a discussion and understand the mood, motivation, etc.

Any suggestions?

Answer 1

Any suggestions ?

I'm sure there is an official Scrum answer and a project management answer. This is a common sense workplace answer: Don't bother.

That person is out of the door. They are there because of their contractual notice period. If they are still doing 7/8th of their work, you got a good bargain. It could be way worse. Don't push it. You have zero leverage, your team has zero leverage.

Whatever their current motivation and/or effort towards your work and team, I guarantee you that discussing it will make it worse. If they are not breaking any of your team's rules, take what you can get as long as you can. You won't get more, not matter what.

Please note that answer is very specifically targeted at the "this colleague is leaving and has their last day already set" part. If it were an ongoing problem with a permanent employee, I would agree with the other answers here.

Answer 2

I tend to agree with Thomas, but this time I might slightly disagree, as I'd suggest a more active stance.

The Scrum Master is accountable for the Scrum Team’s effectiveness. Source: Scrum Guide

You have observed that the team throughput has reduced. You have inferred that it could be because of the behaviour of a team member.

So, as Scrum Master, you might want to intentionally ask the team perception about its deliverables (what do you guys think about our pace of delivery? Are you comfortable with it?) and from this point, carry the conversation to understand what is causing this throughput reduction.

Be intentional to validate if your observation is also shared by the team.

Refrain from imply that you know the reason why the throughput has reduced. It's not about knowing the reason why the throughput reduction has happened. Is about guiding the team for them to identify by themselves the reason(s).

Answer 3

As a Scrum Master, you shouldn't approach this Developer. If the team believes that this is an issue that is affecting their performance, then the team should talk about it at a Sprint Retrospective. If it's truly something that is important, the team should make it an "official rule" and put it in the team's working agreement.

However, coming in late (and leaving early) and not being engaged are different problems. I would consider a lack of engagement to be not taking part in the Scrum events or collaborating with the other developers on progressing toward the Sprint Goal. The number of hours worked and the level of engagement both affect the team's capacity for work but have different root causes and solutions.

Answer 4

I disagree with the other suggestions that you should just ignore this situation because he's leaving soon. Consider the following:

1. Contract end dates can change - what if he gets extended, or if company budget/needs increases and there is a motivation to retain him?

2. A re-energized dev can get a significant amount of work done in a few weeks. Most devs worth their salt can get a project done in a weekend when motivation is high.

3. Most importantly - this is your opportunity to practice having this conversation in a low-risk environment. If the conversation goes poorly, you're relatively sure that he is out the door anyway, so the damage done is minimal. The value gained is monumental - you'll certainty on how to handle this situation again in the future (it'll inevitably happen again).

4. You'd be doing him a service by helping him see that people notice when he drops the ball. I fell into this trap myself as a dev in my mid-career, where I felt like I could just "show up" and that was enough.

As for how to have this conversation, I like your approach of asking questions, and not assuming you know what's going on.

1. Don't assume that he's just being a lazy person (although this is possible)
2. Don't assume that he isn't working outside of the office, as mostly everyone is now.

Time in the office doesn't matter - shipping code does. I would gladly have a strong dev work 6 hours a day, than a junior working 12. The productivity is unequivocal.

If he's not shipping, then you should make sure you give him the opportunity to explain why. If he gives you good technical reasons, then leave him alone. If he says a bunch of fluff, or gives a non-answer, then your work is done. You've pointed out to him that someone notices that he's slacking, and this can create a wake-up call on its own.

This is likely something that will need more than one conversation, and perhaps consulting with other devs to validate your assumption that he's indeed slacking. Story points are a rough metric, so maybe his velocity is "down" but what he really accomplished is on par with the other devs.

Finally, if he is indeed being lazy, and intentionally avoiding work - then this is grounds for terminating even earlier. Why waste 2 months salary on someone who is really just trying to milk an employer.

Answer 5

You'll get a lot of 'ideal' Scrum Master behavior which if not favor at least do not harm engineers; but they do harm you as a leader / scrum master in the organization.

Some might tell you not to approach the developer. That is against the scrum values. As long as the developer is part of the team they need to adhere to the scrum values of openness and respect. Constructive feedback should be welcomed and respected from Day 1 to the last day.

So in no particular order; here are some of the changes you could propose to the team & the developer. (For all the below; I'm assuming you have strong conviction that the team's degrading performance is because of this developer.)

1. Bring out the most important metric from org perspective you would like the team to focus. Make your team understand how it contributes to the org goals. Do this exercise: Make your team members speak out loud the current feature they are working on; when do they expect to complete it and who are they collaborating with in case of any impediments. The goal of this exercise is for them to publicly own features/work items and hold themselves accountable. It also gives you a map of the battlefield: if any features are left out or too many people working on it, does it match the expected timeline, who is overloaded/underloaded, who is at the epicenter (most imp team member), etc. You can then take the important people/work items and strategize around it. Document all of this so that you can present to higher ups about your plan, findings, actions taken and results. If your claim about the developer in question is right; it will automatically put a spotlight on them and the team will need to offload them or pair up with them to get things done.

2. If you do approach them individually be ready to face them with the following data: minimum standard of quality & delivery expected. You don't want to show velocity, because velocity is a team metric and not individual. You want to get a history of the individual's work items, calculate their avg. lead time and any bugs / quality related side effects. Start by 'acknowledging' their efforts so far in the org. How well they started and performed and something you admire. Then 'recognize' the void that will be left when they leave the team. Finally inform them that you do 'respect' their decision to part ways but they expect the same level of professionalism and commitment from them as any other day. Ask them what they are working on currently and when they expect it to be completed. Inform them about the expectations of work and who they need to follow up if they're blocked and define a reasonable amount of time before they ask for help. Everyone has a different work schedule so I wouldn't worry about it as long as they deliver the result. Find someone to handshake / knowledge transfer and keep track of their meetings on a weekly basis.

Your goal as a Scrum Master is to enable people to get things done. Sometimes it means telling unmotivated people to stand up, put one foot in front of the other and teach them how to walk again instead of the team dragging them.

After every meeting with the said developer; send a meeting note listing in short / bullet points: what was discussed, what was agreed, what actions need to be taken, who to talk to and when to follow up.

If you need help, be sure to have a fellow Scrum Master (confidante, esp. better if that someone is outside your org) review your message / ideas / plan of action.

If you're a timesheet based organization and the developer refuses to follow any / all 'requested' & 'agreed' actions after 'multiple' requests; please talk to HR and discuss if not performing 'expected' daily activities classifies as an unpaid day / leave of absence. Give 3 warnings indicating that their last working day might be extended because of this or pay might get affected (confirm with HR / Manager before talking remotely anything about pay). If you're not comfortable talking about pay; just don't. Ask HR to set up a meeting with them.

I do not recommend #2 unless you as a scrum master will directly be held responsible by the client / higher ups for degraded performance. In most situations it is quite understandable that motivation & delivery drops when attrition increases. I would always recommend #1 in worst cases and #2 in the worst of worst cases. If you are new to the organization I would go with #1. If you've been in the org for multiple years and have a good reputation + connections and you face the worst of worst case; I would recommend #2.

Answer 6

It is unsafe to assume that a part of the cause of this situation will be because the developer is leaving the organization in a few months.

You also mention that you are new on the team, so you might want to ask around the team if the team member has always been like that or if it is a new behavior. Specifically, ask the team if they need any help from you as you also need to earn the trust and acceptance of all team members given that you are new.

The information you have gathered should determine if you will be having a one-on-one conversation with this individual, (remember empathy) should you go this route. If this developer claims to be okay and not troubled by anything, then, it is safe to have a conversation with his line manager and politely point out the negative impact on the team thought puts and deliverables.

Another thoughtful way to talk about this is during sprint retros. Together with the team, establish the total hours each member should contribute daily to the development of the project and ensure everyone adheres to it during the next sprint.