How to spot low/high performers within team

Question

We are team of 3 people. We are adapting scrum methodologies.

Everything is based on kanban (trello) where we do daily, retrospectives and sprint planning (the tasks being forecasted by working hours).

Thing is that I have fast developer and slow developer. The fast developer always needs to "make-up" on the slow one. I can spot the slow one because I am at the office, but of course when we grow bigger, it will be hard to spot. We want to spot slow developers in order to improve and take actions. How can we do that the scrum way?

Answer 1

Read this answer with enthusiasm and an open heart :)

I'll answer the question “how to ensure that developers voice slow developers -or. In general any issue-“ instead of “how to detect slow developers” as I think that's not the underlying issue.

The way to accomplish this in a nutshell is:

• Create a safe environment. Everyone should feel safe about voicing their concerns and making suggestions
• Train people on soft skills. Sounds obvious, but, people often don't train themselves in aspects such as communication, ways of working, time management, intra-personal skills (knowing when you need to level up or get help!)
• Make sure that everyone understands the objectives of the project (this is part of communication but I feel it required a separate bullet point)

The major reason for my suggestion is because I think that in the long run this will generate much more value for your team. The second reason is because I think it’s way more easy to detect problems through ensuring that you work with people who will be proactive about issues and solutions than what it is by putting metrics, KPI’s, or in general mechanical systems to review performance (this can only detect what the things they are created for, not new problems that arise as a result of "human-based" issues).

One last note: ensure that retrospectives are done properly. This particular issue with the “slow developer” should’ve been raised during retrospectives and you should’ve spoke about it in an open and transparent way with your colleagues.

I suggest you to have a look at one of my favourite books that expands a lot about working on safe environments and how to increase productivity: Creativity Inc.

Answer 2

I agree with other answers here about the slower person. But why is other person person faster?

I once had someone on my Scrum Team who was so much faster than anyone else:

• They wasted no time validating their ideas with colleagues (e.g. testers).
• They were unemcumbered by team agreements e.g. test-driven development (TDD) approach is much to be slower than simply retro-fitting tests.
• They got ahead of the game by writing code for items still in the Product Backlog.
• They took sole ownership of several vital processes.
• They were loved by end users because they would just fix things (no need to bother the Product Owner!).
• They rapidly re-worked their code whenever testers found a missed use case.
• They didn't distract colleagues in knowledge-sharing exercises.
• They didn't dominate Scrum ceremonies (by never actually speaking).

Yes, they were a terrible team player. We eventually realised we did not want the kind of speed they offered.

Answer 3

Just because a developer is slow does not mean they need improvement.

I am, and have been for a number of years one of the least code productive members of the development team in which I work. Why? Because I am a team lead, I have many other responsibilities which include mentorship, training, stakeholder communication, assisting live issues, and company community development. None of these show up on our kanban board.

Secondly, at the end of the project the only velocity which actually matters is your team's velocity. Your "slow developer" may be working behind the scenes to help the team and as @OneDayWhen points out your "fast developer" may be sitting in a silo and hording knowledge. They may be skipping unit testing which your "slow developer" conscientiously doing.

You asked what the Scrum response to this is. The answer is to use your daily standups to focus on tasks. Your board contains all the tasks which your team has agreed need to be completed to meet the sprint goal. If you're to make it then all the tasks need to be completed.

If a task/story/feature/bug is falling behind and it's looking like it's in jeopardy then raise it at the standup. This could be because your "slow developer" is distracted, or they may be struggling with it. It could also be because someone has been sick or was called into a live incident.

As a scrum team member don't worry about personal performance, that's the manager's job and should be handled in 1:1s. As a scrum master look at tasks which are at risk and ask the team what can be done to catch them back up.

Answer 4

I hope this is obvious but speed to perform a task is not the only criterion against which you would want to rate a practitioner. In many cases, speed may not even be a consideration.

It is also interesting the OP points out only the performance extremes: high, low.

Except for extremely small teams, for mid- to large-sized teams, that dichotomy does not exist.

I think there are three facets that need to be understood when rating your team: 1) the criteria to use; 2) the performance distribution; and 3) the dynamics of having varying strengths and weaknesses that, cumulatively, create a high performing team.

1: Too often we narrow the definition of high performance to one or two criteria while minimizing or ignoring other metrics, similar to this OP's question. Focusing too narrowly on one criterion at the expense of others will cause the label of high performance to be administered to an otherwise mediocre performer.

2: What does the distribution of performance really look like on any team in any domain? Is it normally distributed? Skewed? Most current thinking is that performance is severely positively skewed, where most of your team are mediocre and very few are hyper performers. So perhaps in reality, assuming your criteria are sound, you are really only identifying the hyper performer who might simply stand out.

3) If you only look at your team in a single dimension, you could easily lose sight of other strengths that exist with an individual who may appear mediocre against your criteria, but whose value contributes to the overall team's performance. A slow performer--looking only at speed as a criterion--may offer a high degree of precision in his/her work that could be exploited from a teaming perspective to enable quality in the team's process. So grooming that type of person in that particular team role will enhance the overall team's performance, which is far more important than the individual's performance itself. And remember the concept of The Apollo Effect.

In my practice, I don't bother looking at an individual per se. I look for key strengths to exploit to fill the team's requirements and help the team evolve holistically with those roles. Hyper performers are rare and will simply present themselves over time. Extreme and quite rare low performers will also present themselves and are naturally or unnaturally selected off the team over time. Overall, the most important metric to measure is the team's performance with the underlying assumption that your team will be filled with mediocre to average performers, statically speaking.

Answer 5

TL;DR

Transparency and communication are the backbone of agile practices, and when done right they scale very well. Scrum is based on team performance, and works poorly when you structure the Scrum process as a competition, or attempt to measure individual achievements rather than sportsmanship or teamwork.

Measure the Right Things

I can spot the slow one because I am at the office, but of course when we grow bigger, it will be hard to spot. We want to spot slow developers in order to improve and take actions. How can we do that the scrum way?

A lot of other answers have touched on some great points, but I want to hammer some things home here.

1. From an agile perspective, the effectiveness of the team is what counts, not the relative speeds of individual developers on the team.
2. Measuring coding speed as a primary metric is close to the 100% utilization fallacy in being a Scrum implementation smell.
3. You get what you pay for, so if there's a truly significant skill gap that's impacting your project, you either need to budget for more training to close the gap, budget more in wages for a higher-performing workforce, or both.

Agile in general, and Scrum in particular, are about measuring the ability of a team to deliver business value. A cross-functional team will often have people with varying skill sets, and different abilities and levels of expertise. A good agilist measures the effectiveness of the team as a whole in terms of its ability to deliver value, rather than contrasting members of the team against one another.

Examine Your Assumptions

As a general rule, you want to measure project outcomes, not individual task speed. Instead of assuming you have a personnel problem, examine your initial assumptions. Ask:

1. Are we collectively meeting our project goals on time and on budget?
2. Is the team working at a sustainable pace?
3. Is the team delivering business value without incurring excessive technical debt?
4. Is the development team satisfied with their working agreements and with their fellow team members?
5. Is anyone actually raising an issue, or are you simply assuming a problem exists?

If items 1-4 are "yes" and no one else is raising an issue, it seems likely that you're chasing a false economy of some sort. Measure the right things, ensure you have an effective process, and consistently elicit honest feedback from your team and your stakeholders.

Answer 6

Traditionally, you would have a DevLead, who is responsible for spotting low performers, doing it naturally just by looking how quickly tasks are closed.

By the way, is low performance a problem? If the person complete tasks twice slower and gets twice lower salary, then everything seems ok, right?..

In scrum we should ideally have self-organizing team, where people should assess each other performance. And if low performers damage team velocity, or quality or something and get too much money, then the team will raise it - nobody wants to work with low performers. But if this is just matter of different skill level and experience, then it should be compensated by lower salaries, and they should learn how to do things to raise it.

If it's not compensated by salary, then you should ask your team: we need to complete the project till certain date. If the guy moves us forward, even with low velocity, and there is no alternative person to hire, then it can be better than missing delivery dates.

Answer 7

You seem to have already identified the 'slow' developer. Your team should have a version control system and be tracking work including backlog; much of your concern could be addressed by looking at features completed or at the data after the fact on a daily basis.

Identifying slow developers is either a performance issue where the individual is not skilled enough with the tools and developer tasks, and you should find a new developer or give them time an training to assist them in improving or the reference to "slow developers" is a misdirection and you should consider the management is asking the developer to perform tasks and that management is failing.

Rough order of magnitude estimates are a useful brainstorming tool when trying to gauge overall efforts by the same person that are similar in scope and technologies, can help in maturing the skill set of developers who manage, but not always beneficial to the bottom line. If your 'slow' developer is involved in management, planning, scheduling and queuing of work, then they are not developing.

You may benefit from reading and sharing From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department with your team.

Since this is in the Project Management stack, note your loosely defined issue is not specific to (scrum) agile, project management in software generally can be said to have team members complete work within specific time-frame. Learning to estimate time until completion is a skill. Whether as a developer in estimating how long a new feature will take to implement or as a project manager to determine if the number of people times hours will fit within budget.

Project managers are not typically personnel managers or supervisors. If the focus is on delivery of features by the individual or subcontractor, that may impact project schedule and costs. If the focus is on performance of the individual, that is a personnel issue that should be considered in context of a position description and expectations in hiring contract, along with ability to document when expectations are not met, to allow them to improve or replace them to meet deliverables within budget and time constraints.

Simple measures of number of features independently implemented at each sprint, perhaps with attributes for complexity (e.g., story points), by person can show you speed. It takes context to know of that is "slow" or acceptable to the overall project plans.