Monday, March 05, 2007

Agile Team Evaluations

If you didn't know then I'll tell you now...... I am a huge proponent of XP. I don't much care for Scrum.....it just doesn't work for me, deal with it. I recently read an article "Should a ScrumMaster Give Performance Appraisals?" For those of you who are unfamiliar, a scrummaster is the same as the XP coach.

My first thought was, "who else is really qualified?" My second thought was, "yeah, who else is qualified?!" Now, I'm not a big "Performance Appraisals" kinda guy. Just seeing the words makes me feel kinda sick. I've rarely written a performance appraisal that I didn't wish I could change later. Even when I was in the Army (yes I was in the Army for 12 years) we prepared many "Performance Appraisals" called Evaluation Reports. If it was a good soldier we scowered the last years calendar for good stuff he had done. If it was a bad soldier we scowered their folder for negative things to say. All said, it wasn't very constructive.

Now, to be fair, we did prepare many accurate appraisals. In the Army it's easy. You have a set number training events each year with a very specific set of tasks to be evaluated. You perform these same tasks year after year, event after event. They change sometimes but not often enough to really be noticed. You do well on the tasks.....you get a good appraisal.

Software, generally, is different. Every "new" feature is....well...NEW. In other words an unknown. In most cases, new features involve designing something that has never been designed. So, assuming that the unknown is hard to evaluate, appraising the performance of those working on the unknown must be hard as well...right?

Now that I have argued against "Performance Appraisals" I guess this post is finished...right? Wrong. The author, of said article, IMHO, missed the point. First, a "Performance Appraisal" is very difficult to administer, especially for someone not working closely with the appraisee (is that a word?). Second, software development, especially on agile teams, calls for a completely different approach to appraisals.

We need to accept that an agile team really works as a self organizing organism. No one person can be blamed for the success or failure of a team. That suggests that we really can't evaluate a single person based on the team's performance. So, do we just dispense with "Performance Appraisals"?

Before we answer that we must understand why we have "Performance Appraisals." For most the answer would be, "'cause HR told us to." The ideal answer is "to make the team better", the reality is "to determine who should get a raise" and in the real world both are probably correct. I guess we need "Performance Appraisals"? We'll assume so....

So, how do we design an appraisal that meets both needs (for betterment and promotions)? First, frame it around those competencies that are most valuable to the team. This is where I love XP....values and practices! I'm not going to list them here (it's late) but most intelligent humans could write a set of simple competencies based on the XP practices or the practices of their flavor of agility.

Second, with your handy set of competencies, have each member of your team evaluate themselves and each other member of the team (yes, I know the many reasons this is unpopular). Given the belief that the appraisor should work as close to the appraisee as possible then what bettermethod to use.

Third, sit down with each of them and discuss (yes face to face like human beings) how they did.
Be creative here, each team, depending on it's age and experience will require varying levels of "discussion". For example you may want to talk to them sitting side-by-side rather than "review board" style. Also, use good judgment. Don't just add up the numbers and say "tom" is 5 points better than "john". The whole point is to help the team be more productive. Basically, try to weed out the pettiness and let the person being appraised drive the discussion.

Finally, write an appraisal on each person, as the coach. Each organization will have some different way of recording them. In most cases you'll have little control over this. Either way, the point is to make the appraisal "meaningful" and give the person real insight. Most of all be fair and if you must write anything negative always recommend ways of improving.

Well, that's my rant today. Remember that this (and most of my diatribe) is only an opinion and likely one that could be changed. So, please, no flaming. But, intelligent arguments are not only accepted but encouraged!

4 comments:

George Dinwiddie said...

Dan,

Having managers give performance appraisals to rate employees for raises and promotions is a commonly accepted practice. It's a practice that's not without drawbacks, but that's not the focus of the article you mention (though it does give some suggestions for more effective feedback than periodic appraisals).

The primary point is that turning the ScrumMaster into an evaluator undermines the role of the ScrumMaster as coach and protector of a self-organizing team. Perhaps the conflict between these roles is not clear if you think of coaching as telling people how to do things. Telling people things is perhaps the least effective tool in the coach's toolkit, however.

Maybe in the army you told people how to do things and then evaluated them on how well they followed instructions. It's a simple pattern that works for simple needs. It's limiting, however, in that the trainee cannot exceed the level of the trainer. In creative endeavors such as software development, you generally want to go to a different level. You want to train the trainee to train himself. Rather than provide the criteria for judgement, you want to elicit the creation and refinement of criteria for self-judgement.

I suggest you read through Esther's blog, http://www.estherderby.com/weblog/blogger.html as it will give you lots to think about.

Geoff Slinker said...

I like were you are going with this. I do not believe the Scrum Master should be in charge of performing the performance reviews.

Some quick rhetorical questions:
1) You mention a report. Who is the report for and what is the purpose?

2) Who reviews the reviewer?

Geoffrey Slinker
http://home.att.net/~geoffrey.slinker/maverick/MaverickReviews.html

Agile Jedi said...

I think my point about the Army was missed...I completely agree that the needs are much different. I was attempting to point out that most "managers" are going to give the Army style of evaluation.

George Dinwiddie said...

I was attempting to point out that most "managers" are going to give the Army style of evaluation.

That's fine for the manager. It's not fine for the ScrumMaster.