How can I measure the performance of my team?
What is "performance" anyways? Are we talking about code quality? Soft skills in meetings? Tickets completed? I believe performance isn't really a thing. It is a combination of all things that one does while at work to pursue their assigned goal. So how do you measure that?
Performance reviews are a thing. What is useful data for a performance review? Hours at work? Sentences spoken during meetings? Lines of code? Does any of these actually capture "performance"?
On agile teams velocity is sometimes used as a measure of productivity. Productivity is just a 5 syllable version of performance. Velocity is simply the amount of "story points" a team completes in a given time period. Story points are some arbritray number system where higher numbers equal more complexity.
There are way too many variables at play in order to measure comparative productivity across agile teams accurately. Sure, you can normalize the process across teams, but then you're defeating the whole point of working in an agile way to begin with. Velocity is a pretty shitty performance metric.
Velocity can be useful to ensure a team is working at a sustainable pace. In that they are taking on a mix of low to high complexity work each iteration (sprint) and maintaining the same workload sprint over sprint.
It isn't really worth arguing that lines of code or code quality is any measure of performance. It reminds me of the Picasso Quote about taking 40 years to do a simple sketch on a napkin.
The title of the post is the point: there are no performance metrics. So how do you measure performance? Well, you can't. You can observe it though.
Is it worth counting how many days someone comes into work? Only if they come into work irregularly and it is impacting the work.
Should you track code quality? Of course, in order to pay off your technical debt. Remember that quality is a fluid constraint. Low quality code may be a trade off for speed, or other factors. The quality of the code does not represent the quality of the developer. However, if there is a pattern of the same mistakes being caught in code review then you have another signal for performance assesment.
What I'm trying to get at is you can observe performance, but you can't measure performance. By focusing on what people are actually doing instead of what the numbers say they are doing you will have a clearer sense of their contribution and alignment towards their assigned goal. The observations are extremely useful as specific examples of growth areas during performance evaluations.
Sure, you can collect all the metrics you want, but don't use them to measure performance. Use them to help promote a healthy, safe, and aligned team. That is how you get the best performance out of people.