Sunday, March 28, 2010

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
CEO, Scrum Inc.
Chairman, Scrum Training Institute

Subject: Performance Reviews

There are a lot of reasons not to do performance appraisals. Google doesn't do them. Instead each person has a web page with picture, bio, and three month goals. Each person self-evaluates on the web page. See "Abolishing Performance Appraisals" for all the reasons why performance appraisals don't work.

If you have to do performance appraisals, the attached review process was evolved during the first implementation of Scrum at Easel Corporation in 1993 and enhanced in several leading software companies. Hyperproductive teams have used this process to accelerate their effectiveness. (Hyperproductive 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 starts with a self-evaluation and facilitates a conversation between the reviewer and reviewee:
  • 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 (now GE Healthcare) 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.



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.

Tuesday, March 16, 2010

Dan Mezick on Zombie Scrum Teams!

Abstract

Teams must be authorized to create team culture. They must be 100% free to invent, create, manifest and work inside their own special, unique, meaningful, largely self-determined team culture.

Ground rules set the stage for culture. All else follows. If the ground rules prevent teams from creating culture that is all theirs, then the team is dependent on outside authority and that team can never reach the hyper-productive state. The team is by definition a Zombie team ™.

Click here for details ...

Sunday, March 07, 2010

Roots of Scrum: Takeuchi and Self-Organizing Teams

The first Scrum team was created directly from a paper which is required reading for any Scrum practitioner. It explains how to set up self-organizing teams and clearly outlines management's role in the process.

Takeuchi and Nonaka. The New New Product Development Game. Harvard Business Review, 1986

A longer paper from a book which is out of print goes into more depth. Some may find this easier reading.

Ken-ichi Imai, Ikujiro Nonaka, and Hirotaka Takeuchi. Managing the New Product Development Process: How Japanese Companies Learn and Unlearn.

Also see Takeuchi and Nonaka's books. Their latest books do in-depth analyses of Toyota.

Takeuchi and Nonaka clearly explain the fundamental concepts so often missed by management and teams new to Scrum. The discussion of self-organizing teams is a good example:

A new product development team, consisting of members with diverse backgrounds and temperaments is hand picked by top management and is given a free hand to create something new. Given unconditional backing from the top, the team begins to operate like a corporate entrepreneur and engage in strategic initiatives that go beyond the current corporate domain. Members of this team often risk their reputation and sometimes their career to carry out their role as change agents for the organization at large.

Within the context of evolutionary theory, such a group is said to possess a self-reproductive capability. Several evolutionary theorists use the word "self-organization" to refer to a group capable of creating its own dynamic orderliness. A recent study by Burgelman found that a new venture group within a diversified firm in the United States takes on a self-organizing character. Another study by Nonaka has shown that Japanese companies with a self-organizing characteristic tend to have higher performance records than others.

The creation and, more importantly, the propagation of this kind of self-organizing product development team within Japanese companies represents a rare opportunity for the organization at large to break away from the built-in rigidity and hierarchy of day-to-day operations. It is quite difficult for a highly structured and seniority-based organization to mobilize itself for change, especially under noncrisis conditions. The effort collapses somewhere in the hierarchy. A new product development team is better suited to serve as a mote for corporate change because of its visibility ("we've been hand picked"), its legitimate power ("we have the unconditional support from the top to create something new"), and its sense of mission ("we're working to solve a crisis situtation").

An alternative view of a parallel approach is outlined in:

Chet Richards. Certain to Win. XLibris Corp, 2004.

Richards outlines the strategy of fighter pilot John Boyd. He uses German concepts to illustrate key ideas.

* Enheit -mutual trust, unity, and cohesion
* Fingerspitzengefuhl - intuitive feel, especially for complex and potentially chaotic situations
* Auftragstaktik - mission, generally considered a contract between superior and subordinate
* Schwerpunkt - Any concept that provides focus and direction to the operation

He takes these concepts down to second order interactions. Trust builds by training in the field and by mission driven challenges that a self-organization team accepts or does not accept. It they accept, they can be counted on to do it or die in whatever way they see fit without intervention by the superior. This level of trust depends on the team trusting the rightness of their leader. If superiors do anything to disrupt the team, trust breaks immediately.

With trust based on real unity and cohesion, Boyd's Observe, Orient, Decide, Act feedback loop goes into an implicit state where there is Observe, Orient, and Decisions becomes implicit. The team goes into motion before the leader can give a command. Like in martial arts the Sensei is moving before he even sees the motion of the attacher using a sixtth sense. This is the kind of trust a Dream Team has. You know it when you see it and how come so few software teams have that level of trust?

Thursday, March 04, 2010

Project Management Institute and Massively Distributed Scrum

Non-IT Scrum is of increasing interest. Here is a Scrum run at the Project Management Institute by Dan Mesnick of Agile Boston:
Copyright (c) 2009-2010 Dan Mezick. All Rights Reserved.
Background
Work is increasing distributed; Scrum can be adapted to fit. Some projects have these characteristics:
1. Distributed globally; it is unrealistic to assume that the people involved can get face-to-face time
2. Volunteers populate the leadership and teams
3. The work may not be related to IT or Software
4. The work has fuzzy requirements that are ever-changing and based on events
5. The work has the potential to dramatically scale up or down, meaning the total number of people involved must shift quickly to match
An object example project is the PMI Agile project, where I currently serve as Scrum Master