Rating software teams

It's getting to be "that" time of the year again -- annual appraisal season. Organizations agonize over the best way to appraise software teams, with terms like "scientific", "objective", "measurable", "bell-curve" and "quantitative" resonating everywhere.

Here's what *I* would do. I would measure software teams based on their ability to keep the customer happy. In other words I would look at timeliness and quality of delivery. The *entire* team (managers, analysts, developers, testers and others) would be responsible for and rated on those two metrics.

This would lead to multiple outcomes, some of which are:

1. In order to deliver software on time, the team would make a conscious investment in automation builds, deploys and scripts.
2. In order to deliver quality software, the team would make a conscious investment in testing (necessarily automation if 1 also needs to be satisfied)
3. In order to deliver quality software on time, development standards would be followed like religion.
4. Last, but the MOST important, the team would go out of its way to identify and eliminate deadwood, irrespective of "role".

A lean, mean fighting machine software team :-). Of course, this would work for a *small* organization, not a mid-sized, getting to be large organization.