Time tracking to detect "underperformers"

There are plenty of effective facilitation techniques, although my advice would be to try and bottom out a few things first:

• If a particular team member is "underperforming", why don't the other team members know about it?
• Why is there an emphasis on individual rather than collective accountability? What evidence do you have right now of any teamwork at all?
• Why is an EM determining what "success" looks like and investment optimization strategy? What does the Product Owner, who is accountable for Product value, think about that?

• If a particular team member is "underperforming", why don't the other team members know about it?

Currently, we lack individual performance metrics, making evaluations subjective.

One of the QA team members shared with me their subjective observation that a particular developer is fixing bugs at a slower pace compared to their predecessor. This developer is paid double the salary of the rest of the team, which is a concern for the EM. The EM expects that a higher salary should correspond to increased speed and workload, but currently, this developer's performance is perceived to be on par with those earning a standard salary.

Why is there an emphasis on individual rather than collective accountability?

The EM wants assurance that everyone is performing according to their pay grade, considering it a valid reason to potentially remove an underperforming team member and reduce overall costs.

•  What evidence do you have right now of any teamwork at all?

The team demonstrates positive communication, strong relationships, and effective collaboration. They exhibit a decent level of self-organization, with Developers leading Daily Scrums, facilitating (PBR) sessions as needed, and even managing Sprint Planning. The team consistently achieves Sprint Goals, and approximately 80% of forecasted items are in the 'Done' state by the end of each sprint. All these speak to the team's teamwork.

Why is an EM determining what "success" looks like and investment optimization strategy?

He is not determining overall success. In our organization success is basically "more value with less costs". With value everything is fine for now. With "less costs" EM is trying very hard to figure out.

What does the Product Owner, who is accountable for Product value, think about that?

PO is pretty happy with team's work and their speed of delivering value. However EM with a background as a former programmer on the product and a deep understanding of the codebase, believes that despite the PO's satisfaction, the team could have accomplished the same results in just one week (instead of 2). Basically if that was the case it would possibly let him to have one feature team instead of 2, and save money.

One concern I would have is that this form of micro-management might lead to Developers cutting corners to finish work. Might they skip refactoring code or writing unit tests, which leads to tech debt? Might they skip running some tests and leave work undone now that time is being tracked?

Another concern. Would they be willing to take time out to collaborate and help each other if they are worried about their time being tracked?

I agree with Chris, this is fraught with danger.  Someone that is not technically part of the Scrum Team micro-managing them, when the PO & SM are both happy, may not end well.  And let's be realistic, what Scrum Team members spend 8 hours a day with hands on keyboard or headset on in a meeting?  Perhaps the EM needs to reset their expectations a little.

If you can provide a safe enough environment, I'd encourage discussion in a retro.  Your challenge will be to keep it strictly about the effectiveness of the Scrum Team & not a personal attack.

Alternatively, we've been doing regular F360 surveys where we all comment on the effectiveness of each Scrum Team member.  It's a bit more private & acts as a conversation starter between a couple of people rather than the whole group.

Hello Everyone,

Thanks for sharing your experiences. I am grateful to you after reading all the information about Time tracking to detect underperformers

PO is pretty happy with team's work and their speed of delivering value. However EM with a background as a former programmer on the product and a deep understanding of the codebase, believes that despite the PO's satisfaction, the team could have accomplished the same results in just one week (instead of 2). Basically if that was the case it would possibly let him to have one feature team instead of 2, and save money.

Please - let him proof that he can do it. 

Next, if he really was able to do that, discuss how to bring team members on his level of knowledge.

If everybody is then on that level, start your discussion of time tracking.

Everything else is comparing apples with something else.

To me, it is not yet clear what is the real problem. Depending on the problem there are different angles to approach the situation. Is it that:
a) the EM has an individual goal (cut costs) that's opposed to the team's goal (work towards Sprint Goals and Product Goal)? 
b) Is it that a developer is unable to fulfil his potential or simply not meeting expectations? 
c) Is it that the company needs to cut costs? 
d) Is the team ineffective? 

Here are some suggestions:
a) Maybe it is worth talking with the stakeholders outside the team who set those cost-goals for the EM, the EM and Product Owner. Together, consider, how much invest (i.e. salary) they are willing to pay for the continuous value increase of the product the team delivers. If the delivery is great now, are they willing to take the risk that delivery will slow down after cutting costs?

b) If the EM has an indication that this one developer is not living up to his responsibility as a team member, he could talk to that person directly. They both have programming experience. You could help the EM practise violent-free communication or other ways of giving resourceful feedback. Instead of crushing a person by saying they are doing a bad job, the EM could state his observations and ask how he can be of help for his fellow developer. You wrote it was his job to teach sound engineering practises. So if he sees potential in a colleague, why not address it directly with the colleague and help him/her? 

c) If the team has to cut costs no matter what, although they are all doing a good job, you could take that problem to the team and be transparent about it. Maybe a person from leadership is better suited to deliver the message, since it was not your decision. Instead of looking for a scapegoat, it is better to be transparent about the fact that the company needs to cut costs and not blame it on one developer instead.

d) Another option could be doing a self-assessment with the whole team on their effectiveness. How effective do the developers, PO, EM consider the team to be? What is stopping them from being more effective? What could help them tap into their potential as a team? 

It's a sensitive topic. Apparently the team is delivering what is expected from them. They are reaching their Sprint Goals. Anything that could be considered as punishment (like micromanagement though timetracking to measure individual performance) could backfire and affect delivery and motivation heavily. 

I worked with a team once where the most senior developer submitted the least amount of code to the repository but they were considered one of the most productive and important members of the development group.  Why?  Because they spent a lot of time working with the other developers discussing options for changes, reviewing code, discussing future items with the Product Owner to prepare for better refinement by the team, and much more.  They used their experience to help raise up others on the team and as a result, that team became a role model for the organization. 

Time tracking, especially in the way that Jira has it implemented, would not show this individual's contribution.  Maybe it would be helpful if you worked with the Engineering Manager to define what "productivity" means for the different levels of developer seniority.  Right now his view is too simplistic and more suited for a production line making car parts than software development.  He is looking for a simple, quick fix for a problem that he doesn't fully understand. Until you know exactly what you are trying to measure, you can be pretty sure that any attempt to measure it will be flawed.

Any metric, once set as a target, can lose its effectiveness as a measure and potentially do more harm than good.

I favor Lea's approach: engage in direct communication with the individual and the team, but proceed with sensitivity. There's a possibility that our suspicions might be unfounded, and every person in question deserves an opportunity to be informed and to offer their perspective. It's important to remember that most people work because they take pride in their contributions. While mistakes are a natural part of the human nature, when these are constructively pointed out, individuals often welcome the opportunity to make improvements or correct their course. This approach not only fosters a culture of accountability but also one of continuous growth and respect.