I know it should not be done, but I'm tasked by my company to measure the performance of each person on the Scrum team. What would be a "not so bad" way of doing it?
P.S. I cannot let the team decide how to do it.
Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.Sign up to join this community
You already know you shouldn't do this. However, if you must do it, focus on team integration and support of team values, rather than trying to perpetuate the 100% utilization fallacy or applying irrelevant metrics like lines of code written or bugs stomped per iteration.
If the person makes the team better or the process more effective, then they are valuable. If the person reduces team cohesion or effectiveness, then the team should "vote them off the island." It really is just that simple.
You can't really measure individual performance on a Scrum team, but you can measure an individual's level of participation in the team's process and (to some extent) how well they contribute to the team as a whole. For example, you might design a questionnaire that asks some team-process questions like:
Team Member: ______________________________ 1. Does team member attend all framework-mandated meetings? 2. Does team member follow all framework processes? 3. Does team member produce work that meets the team's Definition of Done? 4. Does team member actively participate in the Daily Stand-Up? 5. Does team member participate appropriately in Sprint Planning? 6. Does team member participate appropriately in Sprint Reviews? 7. Does team member participate appropriately in Sprint Retrospectives? 8. Does team member pair well with others? 9. Does team member value collective code ownership? 10. Does team member strive for continuous improvement and cross-functional learning?
If management's goal is to try to figure out whether Team Member #7 is more or less valuable than Team Member #3, then management has missed the point of Scrum. The real question is whether each team member adds value to the team, and whether the team would be better off with or without that person.
If the person makes the team better or the process more effective, then they are valuable, both to the team and to the organization. If the person reduces team cohesion or effectiveness, then the team should "vote them off the island." Any other measure of "value" is not embracing the core agile principle of valuing "individuals and interactions over processes and tools."
The most important thing is that the team is as productive as it can be. Measuring individual performance is not very important within Scrum.
Scrum teams are supposed to be self-organising, so different team members make take slightly different roles. For example, I worked on a team where senior members of the team would take the "harder" bugs, but they would solve fewer than the more junior team members.
A performant Scrum team requires the team members to work in a certain way. There are too many details to list here, but you want the team members to respect the rules and contribute in Scrum ceremonies/meetings. For a team to be self-organising, you want your team members to be pro-active. You do not want to have to micro-manage your team. You should make sure the performance criteria align with these behaviours.
You've said, that, "you can not let the team decide".
Really? 360 degree feedback is a common way to gather feedback about employees. I've recently been measured in this way. I'm certainly sure this should be part of the way you measure the performance of your employees.
However, if you really can't let the team members do this, then can you at least let them have some input on the criteria which you measure them on. What do they think the perfect team member is? How do they measure up to it?
We broke the Scrum process a bit by keeping the titles (Senior, Mid, JR), but only for salary and compensation benchmark.
To keep it on the fair side, we have a SR in each Scrum Team (also called technical lead, but not people lead, so not manager; they are supposed to lead the technical side of the product).
Tools we use:
The system is quite fair. The salary brackets for each level is open to everyone; where everyone is is also public to the entire team. So they kind of know their own salaries, it's all fully transparent.
When we communicate the restuts to the devs, they have an occasion to contradict us (with facts). Never happened so far :)