Evaluating individual performance in Development Team
I am KK, from Malaysia, and I am new here in Scrum.org.
I have one question on evaluating individual performance in the Dev team in Scrum.
As we are aware, Scrum is all about collaboration and self-organizing teamwork. Some even argued that prioritizing on individual's performance is arguably violating the principle of Agile / Scrum. Having said that, in the real world, organizations will still need to appraise individual performance for career advancement and also monetary reward. From the organizational and HR front, it's kind of unrealistic to evaluate everyone by their team output only. The reason is doing so will diminish the contribution of the top performers and might negatively affect their career development as "everyone is now equal" in the development team. Additionally, the low performance of certain team members might not be addressed as well. Of course, in an ideal world, we would like all team members to perform at their best and exactly the same level, though this might not be realistic. I know we can use 360 degree feedback to gauge the feedback on individual team members, but 360 degree feedback has its own drawback in terms of biasness.
Any other idea?
Many thanks in advance.
What skills are in shortest supply for completing "Done" work, and for implementing Scrum well? Does management care enough about the removal of organizational impediments to agile practice that it will reward those who achieve such competencies?
Thank you @Ian for your pointers. Do you have any idea on what metrics could be used to assess the performance of the development team members in what you have suggested? I assume that we can't use any of the scrum related metrics such as individual velocity or cycle time, because they were not meant to gauge individual's performance, or can we?
I have another question related to this as well. Is it ok then to promote a development team member into senior role since Scrum advocates that there is no hierarchy in the team? What I mean by senior is someone who has the experience and skillset needed to guide the team, not someone who has the management authority.
Thank you once again.
Do you have any idea on what metrics could be used to assess the performance of the development team members in what you have suggested?
I'd suggest that t's the ability of the organization to deliver the best value in a timely fashion that needs measuring.
Those who help to remove organizational impediments to productivity then ought to be rewarded. How that help is measured would depend upon how the organization makes its impediments transparent in the first place. How does it enumerate them? Which are the most significant pain-points, for which resolution would be of the most value? Does the organization need more security expertise for example, or more technical writers, if Done increments of work are to be completed and released more often?
Is it ok then to promote a development team member into senior role since Scrum advocates that there is no hierarchy in the team? What I mean by senior is someone who has the experience and skillset needed to guide the team,
Might that so-called "promotion" to a "senior role" effectively cover up, and thereby accommodate, a weakness in the team's ability to self-manage and to share accountability for outcomes?
Thank you @Ian.
if Done increments of work are to be completed and released more often?
Let's say there is a more productive developer who always complete the work (getting it to Done) twice as fast compared to the rest of the team and with better quality. If the organization were to reward this developer higher compared to the rest of the team, would that go against Agile which emphasizes on teamwork rather than individual performance? But on the other hand, if the organization attribute the good work to the team as a whole rather than highlighting this particular individual developer's performance, wouldn't it demoralize the top performer to a certain extent?
I understand that in Agile, the performance appraisal should focus more on the contribution of the developers towards improving the Agile process (and removing impediments) and to the team as a whole, but what about differentiating the developers by more conventional and technical metrics, such as number of bugs in codes, speed and quality of delivery, etc? Even though the whole development team should be accountable and responsible for delivering the increments in Scrum, but realistically more often than not, we usually have each task being assigned to specific development team member. So in this case, there should always be a difference between the team members according to the aforementioned conventional and technical metrics, which subsequently merit different rewards between the team members. What do you think?
It's the team which is productive and which completes increments of work If productivity is somehow being measured in terms of the individual developer, there's your problem right there. Why is such a measurement even being taken?
I'd suggest that if the team believes certain individuals are less able than others, and that it is affecting morale, they might address and resolve the matter no later than the next Sprint Retrospective.
While OKRs can be annoying, a team can create them on an individual level and on a team level. Each team member will take responsibility for their objectives and also the team objectives. You should be able to see who promises a lot and doesn't deliver, even as you see team goals achieved as a group.
I also notice how long an issue has moved between sprints. The length of time in a sprint can generate the background required to ask that team member on a management level why goals and their own estimates aren't being reached. Could be outside impediments, or it could be lack of knowledge, and yes just plain laziness. "Hey, I'm in an agile team now, I can coast!" A scrum master or agile leader should bring these trends to the attention of managers, not as a big brother but just seeing the data trend.
@Ian, the reason why organizations measure at individuals level (organizations also measure at team level though) is because no matter how much we would like everything to be measured on the team, realistically there will always be difference in the performance of individuals in the team. In my example, I must emphasize that it doesn't mean that the rest of the team is performing badly, they could be performing up to mark as well, though one or two particular developers are just performing at a more outstanding level technically. Well, of course over time with training and experience, the gap between the good developers and the outstanding ones could be bridged, but until that moment arrives, don't you think the top performers shall be rewarded higher as motivation and appreciation for their outstanding contribution? From the organizational perspective, this is to ensure that they retain the top talents. From the outstanding developers' perspectives, this provides them with a motivation and channel for continuous career development. I would say typically many developers would like to continue growing and climbing the career ladder (just like any employee), hence I came across some arguments which say that Agile somehow inhibits that because the emphasis is only on the team only, hence everyone in the team should always be rated as a whole. So in that case, how would the organization be able to promote a developer to roles like e.g. technical lead, team lead, VP, and so on? I know such roles might not be championed in Agile, but realistically those roles always exist in organizations.
@Jonathan, yes, what you said was what I meant. Do you have any experience on how the actual measurement is done on the individual and team OKR? Do organizations use metrics such as velocity, cycle time, lead time, etc based on tasks assigned to individuals to compare their performance, in addition to maybe 360 degree feedbacks or anything as such?
Well, of course over time with training and experience, the gap between the good developers and the outstanding ones could be bridged, but until that moment arrives, don't you think the top performers shall be rewarded higher as motivation and appreciation for their outstanding contribution?
In Scrum, the principal time-box we have and care about is the Sprint. That's a recurring bounded environment within which a team can take action, and resolve any issues concerning individual capabilities. At all times, it's the productivity of the team which ought to be assessed and measured.
Thank you @Ian