My previous entry was all about how individual performance metrics in a collaborative, agile environment are misguided. But to keep things focused on reality, where demands for such metrics are sometimes unavoidable, I ended on a challenge for myself to come up with some individual, quantitative performance metrics that did not conflict with notions of self-organization, trust, collaboration, teamwork, and all that stuff that makes agile development teams happy and productive.
While driving home from work I came up with a couple of ideas.
To begin, I’ll jot down some attributes of what I would consider an acceptable individual, quantitatively measurable performance metric.
- [ ] it is not adversely affected by taking time to help others
- [ ] it is not adversely affected by doing high priority work over high complexity work
- [ ] it does not discourage doing high complexity work for fear of failure
- [ ] it makes individual praise sensible and individual punishment nonsensical
- [ ] the closer to an ideal value it is, the more successful the team at delivering valuable work
- [ ] it does not loom over people’s heads and lower morale
Let’s say that if an idea ticks all six of the boxen, then it’s fully acceptable. If it doesn’t, then it’s to be avoided. With that in mind, let’s look at a handful of “candidate” metrics.
I ranted about this at length in my previous entry. This metric fails points 1, 2, 3, and 6, and makes a weak case for passing 5. It incentivizes selfishness and compromises team collaboration.
Defect count per person
Whether used to evaluate developers based on how few defects are discovered in their work or to evaluate testers based on how many defects they dicover in others’ work, this metric fails points 3 and 6. In the case of evaluating testers for, effectively, reporting how crappy the developers’ code is, it also fails points 1 and 5.
Number of lines of code
Ok on to the ideas that I think might at least be conversation starters…
Contributions to an “agility index”
This one came to me while reflecting on a conversation featuring Ken Schwaber and the notion of having an Agility Index that would indicate how “agile” a company is. From what I could tell, it amounted to a checklist of agility-enabling practices that in turn yielded a score between 0 and 100. While I can’t seem to find this particular checklist on Scrum.org — presumably they’d want to sell its usage — I think a comparable checklist can be formulated by anyone with sufficient experience. The more items checked off, the higher the score on the “agility index.”
Making progress towards a higher index benefits the entire team and should not compromise any other good practices. In other words, all six requirements mentioned above would be met. What’s left is figuring out how to make it a quantifiable individual measurement. Well, when it comes time for a performance evaluation, simply ask each developer to mark the “agility index” checklist items that he or she contributed to, with a short blurb specifying the nature of the contribution. The more items contributed to, the better. And the nature of the items should ensure that nothing beneficial got compromised.
Kudos received through team retrospectives
This one is a bit wacky, but I think it’s worth a go. Some variations on team retrospectives include “giving kudos” to fellow team members. These could be for help offered, or ideas presented, or the quality of some deliverable, or really anything at all that was appreciated by others on the team. By being all about collaboration and contribution to team success, this approach ticks all six of the above boxes. And if a process or project manager keeps track of the number of “kudos” each team member receives, that can later be turned into a performance indicator.
So, that’s what I came up with on my drive home. There may be other things of this nature that focus much more on success than failure, and team success at that, all the while allowing for an individual perspective. And I think these are the kinds of metrics we should focus on if we absolutely have to. If it were up to me, I’d just focus on enabling team success.