Ask HN: How does your company do performance reviews?

A colleague of mine always said: you get what you measure.

1. We have an in-house developed tool that tracks git and mercurial commits and calculates the test coverage and code quality for each individual developer.

2. We use jira to track the number of points each developer burns (points are shared between developer, reviewer and QA). We also track the number of bugs each developer introduces because closing a bugfix is not possible without first assigning the developer who introduced the bug to the jira task.

3. We use peer reviews where each team member rates each other team member on a scale from 1 to 5 (3 being considered sufficient) on aspects like availability, communication, reliability and result orientation.

4. Team leaders offer subjective input on each team member.

Of course, many of the metrics will be skewed or won't reflect the reality, which is why the team lead has the right to make adjustments to the final mark.

This being said, one of my colleagues and friend was "forced" to quit the company because he scored really low on the jira burn rate metric. He was given a tremendously huge task which nobody cared to properly estimate and break into smaller tasks. As a result he spent 6 monts working on the equivalent of 2 weeks of estimation points. The management (including the team lead which is otherwise a great leader and an awesome person) didn't want to assume any blame for this.

Over a period of time we started using Impraise (impraise.com), although it's not the best tool - it helps people to force to take the time and leave there current mindset to focus on something like giving feedback (on an equal base, because some people are just very good at giving feedback and keep on talking, while others are struggling and need to write it down). Every quarter, you review 2 other people. People read it, interpret it and carry on. However, I sit down with them after everyone has filled in the questions on Impraise (which are not the default ones, but they're pretty straightforward, like: "how good is the quality of your colleague's work?"). This information is used as a base to allow me to ask even more questions, like: "do you agree with this statement?" or "what could you do to improve this situation this colleague is describing?”. The result of this conversation are 4 things:

1. self reflection,

2. setting personal goals (which is mostly one of the things from the self reflection, getting more focus/attention than other things, which is not shared within the team),

3. create and/or help out with team goals, something we should improve as a team and shared within the team,

4. feedback on the process itself.

These results are written down as notes and then reflected on the next time we sit down.

We have some other tools, methods and things in place to have more of a continuous feedback loop - but it remains a living thing, rather than a set in stone method. If you have questions, you're always welcome to contact me :-)

Aggregating them for an individual developer over a long enough period of time might work, but I wouldn't trust it without some statistical hypothesis testing backing the idea up.

But using them to evaluate productivity on a small scale violates the collaborative culture (people over processes) that agile is supposed to foster. I've also seen them misused by:

  * mapping them explicitly to hours or days

  * thinking they are estimates of value produced instead of work required

  * having project managers point and pull in things for developers

But, no, I've never heard of agile mistakes coming up in a performance evaluation or a 180 review for a manager.