Wednesday, November 29, 2006

Agile Performance Reviews


MEMO – June 1996 (updated Mar 1997 for IDX RISD, Feb 2000 for PatientKeeper, Nov 2006 for Scrum Alliance)

To: All Development Staff

From: Jeff Sutherland
VP Engineering, Individual
SVP Engineering and CTO, IDX Systems
CTO, PatientKeeper

Subject: Performance Reviews

Over the past 10 years, the attached review process was evolved during the first implementation of Scrum at Easel Corporation in 1993 and enhanced in several leading software companies. Hyper-performance teams have used this process to accelerate their effectiveness. (Hyper-performance teams deliver product in record time and computer journal editors write rave reviews and say it is the best product of its type that they have ever seen.)

This review process:

  • Allows the review to be a better means of communication with an employee.
  • Helps build mutual understanding on performance, personal goals and objectives, company goals and objective, training needed, and objectives for the next three months.
  • Makes the rating system more objective by focusing attention on the user experience of the product being developed, along with time to market. The subjective experience of the manager is deemphasized.
  • Require raters to all work closely with one another to sanity check ratings. It is not easily managable on a large, impersonal system, as currently used in the IDX peer rating system in 1997.


The Process Takes Three Meetings to Initialize

Meeting 1: Reviewer meets with employee and goes over this document. The employee is then asked to write his own individual review after the meeting by responding to the key questions (see below) and giving him/herself a rating. The employee can write a little or a lot. This review is designed to minimize the amount of writing.

Meeting 2: The second meeting occurs when the employee returns the review (along with soft copy). The reviewer discussed the employees perceptions to get a good understanding of them. After the meeting the reviewer carefully edits the review to incorporate the reviewers perception of performance.

Meeting 3: The third meeting occurs after the reviewer has finished editing the review and the ratings. The updated document is carefully discussed with the employee. Any difference in perceptions is noted. If there is any disagreement, the employee may convince the reviewer to change the review or, failing that, write a rebuttal that will be attached to the review. After changes are incorporated, the review is signed by both reviewer and employee, as well as the VP of Engineering..


The Review Ratings

It is well known that employee performance ratings in all organizations are inflated. This process is designed to produce realistic, provably accurate, ratings. Ratings tend to reflect how well the employee sucks up to the manager, rather than whether or not the employee generated a great product that led to lots of sales and happy customers. We have to get away from motivating employees to please the manager, and get them to please the customer.

The higher rating supercedes the lower. If the manager gives a 4 and the team gives a 7, it is a 7 and so forth. This review is a form of 360 degree feedback where the review process is designed to surface gross disparities between market perception, customer perception, company perception, team perception, manager perception, and individual employee perception of their performance. Gross disparities are rare and should be dealt with on an exception basis.

Ratings on the review are scaled from 1 to 10:

10 Trade journals are writing rave reviews about your work saying it is best in class

Historically, two teams scored a 10 with this system. The first was the original Scrum team at Easel Corporation for delivering Object Studio (ScrumMaster: John Scumniotales). The second was at IDX for delivering a new Enterprise Master Patient Index System (ScrumMaster: Mary Rettig).

9 Customers are writing rave reviews about you (must be documented in writing)

8 Exceeds expectation of the company senior management

7 Exceeds expectation of Product Owner and Team

6 Exceeds reviewers expectations

5 Meets reviewers expectations

4 Does not meet reviewers expectations

3 Does not meet development teams expectations

2 Does not meet Engineering group or company expectations

1 Customers are complaining about you

0 You are personally roasted in PC Week

Under this system, the manager can give a 4, 5, or 6. Any other rating requires outside input from the development team, the engineering group, senior management, customers, or the press. The employee can always write a rebuttal to any review and have it attached to the review as part of the human resources record.


Review Template

The attached document provides a template for the review.


Ongoing Reviews

One an initial review is written, it becomes the template for the next review. Subsequent reviews can be done easily and quickly with this template in place.

2 Comments:

Blogger Joel said...

Interesting - I've been reading lots of different thoughts around Performance reviews and scrum. This is another interested approach as it human nature to want to have goals and to have measures.

One interesting off shoot of this is who should be conduction the review? Most seem to say the Scrum master doesn't but how do you keep an organization nibble when you have some of this overhead?

3:33 PM  
Blogger Jeff Sutherland said...

As the manager, I have done these reviews with a lot of input from the ScrumMasters and the teams. In large companies, we created a resource manager position to do these and other administrative tasks to support an organization where all managers were leaders of teams and expected to lead, not just adminstrate.

5:52 PM  

Post a Comment

<< Home