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.
-
3Why couldn't you let the team decide :). Can't you give them boundaries to work within?– jessehouwingJan 17, 2014 at 15:33
-
You may not like the question but it is the situation that i am in. We are in a scrumbut enviroment. My manager has hard time understanding the concept of team.– AasimonJan 18, 2014 at 20:43
-
"I know it should not be done", actually I don't think that is true. Measuring productivity is very difficult and you shouldn't bother. But you do want to ensure that the team members are performing and that you need a transparent process for that. I would not try to measure team members relative performance, as long as they meet the minimum standards.– Dave HillierJan 18, 2014 at 22:03
-
I understand the question and do not like the circumstances you are in. On the other hand teams can decide on performance without knowing how much poeple get paid. Let them rate themselves, then hold that against what is expectd of them.– jessehouwingJan 19, 2014 at 18:47
Add a comment
|
4 Answers
TL;DR
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.
A Teamwork-Oriented Scorecard Approach
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?
Defining Value
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."
answered Jan 17, 2014 at 22:12
-
Great Answer. My manager is trying to figure out how much raise he should give to each person. In my company it is forbidden to talk about salary. So i am asked to give my opinion about their performance. By the way i would give you +1 but system does not let me yet.– AasimonJan 18, 2014 at 20:48
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?
-
Thanks Dave, I havent thought of 360. My company is still struggling to fully integrate Scrum, in the mean time we are still in Scrumbut enviroment.– AasimonJan 18, 2014 at 20:53
I am not sure how you can calculate performance of an individual when Scrum is based on a Team environment. An individuals performance can be tracked by setting his/her goals and tracking if those goals are met within the given time frame.
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:
- feedback 360 (in case the SR in a team is biased regarding the people in the team)
- feedback from the SRs on their technical capacity and from SM on their process knowledge (90% of the time the feedback 360 and the SR/SM feedback as similar; when discrepancies, we ask the CTO to find the facts)
- we also ask the entire team where they position themselves, where they want to be and what they need to get to the next level
- with all the information above we have a meeting (the seniors in tech), we look at where they position themselves; if nobody disagrees and the feedback is on point, we position the dev on the level he chose for himself; if feedback or SRs say different we have a discussion, we motivate why we don't see the dev on that position and what they have to do to actually be there (with a timeline and a responsible mentor / guide for them).
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 :)
