[SCRUMDEVELOPMENT] Performance Reviews

[Charles Bradley - Professional Scrum Trainer and Coach [e-mail] [SCRUMDEVELOPMENT]]

Ron, I agree that it is unclear... but let me see if I can make it better, then if I can, I'll suggest changes to Jeff (He and I had traded emails earlier on clearing up the article).
Imagine these notes under the headings as such:
The Process Takes Three Meetings to Initialize
(In the Review Template linked down below, this section refers to the "Individual Performance" part of that Review Template)
and..The Review Ratings(In the Review Template linked down below, this section refers to the "Development Team Rating..." part of that Review Template)
While this may not be the best way to fix the article -- does the above help your "shared understanding" of how the review process works?

(One other "hole" is who does the "Company Rating" on the Review Template)

-------
Charles Bradley
Chief Executive Officer
Professional Scrum Trainer
http://AgileSoftwareTraining.com
Agile Software - Training, Consulting, Coaching

From: "Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Sunday, May 31, 2015 4:06 PM
Subject: Re: [SCRUMDEVELOPMENT] Performance Reviews

<!--#yiv6689767518 #yiv6689767518 .yiv6689767518ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv6689767518 div.yiv6689767518ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv6689767518 div.yiv6689767518photo-title a, #yiv6689767518 div.yiv6689767518photo-title a:active, #yiv6689767518 div.yiv6689767518photo-title a:hover, #yiv6689767518 div.yiv6689767518photo-title a:visited {text-decoration:none;}#yiv6689767518 div.yiv6689767518attach-table div.yiv6689767518attach-row {clear:both;}#yiv6689767518 div.yiv6689767518attach-table div.yiv6689767518attach-row div {float:left;}#yiv6689767518 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv6689767518 div.yiv6689767518ygrp-file {width:30px;}#yiv6689767518 div.yiv6689767518attach-table div.yiv6689767518attach-row div div a {text-decoration:none;}#yiv6689767518 div.yiv6689767518attach-table div.yiv6689767518attach-row div div span {font-weight:normal;}#yiv6689767518 div.yiv6689767518ygrp-file-title {font-weight:bold;}#yiv6689767518 -->

Hi Charles,

On May 26, 2015, at 9:51 PM, Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:
I'm not seeing what you're talking about.  Can you be more specific?

Reluctantly, here are some thoughts. Reluctant, because ideally they’d be addressed privately to Jeff, not to this group. But you did ask.
In essence the core algorithm of the article comes down to:

- Employee rates self;
- Employee and reviewer discuss ratings;
- Reviewer rates employee;
- Employee rating stands.

At this moment the reader is all WTF, the employee rating stands??. What follows doesn’t help alleviate the WTF.
In particular this section:

The higher rating supercedes the lower. If the reviewer 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, reviewer perception, and individual employee perception of their performance. Gross disparities are rare and should be dealt with on an exception basis.


 seems to be saying that there is a team rating. Are we talking about a single employee, rated by their team? If so, there’s something missing above? Are we talking suddenly about how to rate a whole team (which could be a good review idea)? If so, then the first part should have said “Team rates itself”, etc ...
The quoted section goes on to refer to a number of “perceptions”: market, customer, company, team, reviewer, individual. (Likely this should have been a new paragraph.) Either way,t the procedure itself only addresses what the reviewer and the individual do. Somehow a whole bunch of people seem to have popped into the equation. Compiler explodes with “undefined term” messages.

Naturally, I can imagine an answer. the problem is, I can imagine many disparate ones, mostly wrong.
One candidate answer is: “either the employee or reviewer may make [un]substantiated claims about the views of other individuals or groups regarding the employee’s performance”. If I guess that, which seems a possibly sensible thing to do, I’m still left with a huge gap in understanding how those claims would be created, used, assessed, or adjudicated. It also puts quite a burden on the other people involved, since in fairness, the employee and the reviewer should both be engaged in getting this information. (Together, one would have hoped, but together isn’t part of this scheme.)
Another answer might be “use common sense”, which makes the questioner go away but each questioner goes away with a different answer in his head, since “common sense” is never common and often not sense. 
Overall, in my opinion, the article leaves too much to the imagination, which means that this advice will be used, if at all, in random unintended ways. The rubber doesn’t meet the road. 
Ron Jeffriesronjeffries.comIf not now, when? -- Rabbi Hillel

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hi Charles,

Post by Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT]
Ron, I agree that it is unclear... but let me see if I can make it better, then if I can, I'll suggest changes to Jeff (He and I had traded emails earlier on clearing up the article).
The Process Takes Three Meetings to Initialize
(In the Review Template <http://jeffsutherland.com/review_template.html> linked down below, this section refers to the "Individual Performance" part of that Review Template)
and..
The Review Ratings
(In the Review Template <http://jeffsutherland.com/review_template.html> linked down below, this section refers to the "Development Team Rating..." part of that Review Template)
While this may not be the best way to fix the article -- does the above help your "shared understanding" of how the review process works?
(One other "hole" is who does the "Company Rating" on the Review Template)

Might work. As it is, it won’t compile, much less run. :)

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Master your instrument, master the music, then forget all that shit and just play. -- Charlie Parker

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

I appreciate the responses. The best they are going to do now is heavy weighting to individuals who cause team success. It was a win for me just to have them let go of putting their initials on the task stickies for the purpose of getting individual credit. "Small moves, Ellie, small moves.” :)

Post by Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT]
Hi Charles,

Post by Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT]
Ron, I agree that it is unclear... but let me see if I can make it better, then if I can, I'll suggest changes to Jeff (He and I had traded emails earlier on clearing up the article).
The Process Takes Three Meetings to Initialize
(In the Review Template <http://jeffsutherland.com/review_template.html> linked down below, this section refers to the "Individual Performance" part of that Review Template)
and..
The Review Ratings
(In the Review Template <http://jeffsutherland.com/review_template.html> linked down below, this section refers to the "Development Team Rating..." part of that Review Template)
While this may not be the best way to fix the article -- does the above help your "shared understanding" of how the review process works?
(One other "hole" is who does the "Company Rating" on the Review Template)

Might work. As it is, it won’t compile, much less run. :)
Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Master your instrument, master the music, then forget all that shit and just play. -- Charlie Parker

[Eric Gunnerson [e-mail] [SCRUMDEVELOPMENT]]

I think that’s a decent place to start; we are something like that.

What we found is that since everybody did their individual work, how well they helped others be successful became a differentiating factor, though perhaps not as obvious to the team members as I would like.

Eric
From: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Saturday, June 13, 2015 10:40 AM
To: ***@yahoogroups.com
Subject: Re: [SCRUMDEVELOPMENT] Performance Reviews



I appreciate the responses. The best they are going to do now is heavy weighting to individuals who cause team success. It was a win for me just to have them let go of putting their initials on the task stickies for the purpose of getting individual credit. "Small moves, Ellie, small moves.” :)


On Jun 12, 2015, at 4:30 PM, Ron Jeffries ***@acm.org<mailto:***@acm.org> [SCRUMDEVELOPMENT] <***@yahoogroups.com<mailto:***@yahoogroups.com>> wrote:

Hi Charles,

On Jun 12, 2015, at 6:25 PM, Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com<mailto:chuck-***@emailchuck.com> [SCRUMDEVELOPMENT] <***@yahoogroups.com<mailto:***@yahoogroups.com>> wrote:

Ron, I agree that it is unclear... but let me see if I can make it better, then if I can, I'll suggest changes to Jeff (He and I had traded emails earlier on clearing up the article).

Imagine these notes under the headings as such:

The Process Takes Three Meetings to Initialize
(In the Review Template<http://jeffsutherland.com/review_template.html> linked down below, this section refers to the "Individual Performance" part of that Review Template)

and..
The Review Ratings
(In the Review Template<http://jeffsutherland.com/review_template.html> linked down below, this section refers to the "Development Team Rating..." part of that Review Template)

While this may not be the best way to fix the article -- does the above help your "shared understanding" of how the review process works?

(One other "hole" is who does the "Company Rating" on the Review Template)

Might work. As it is, it won’t compile, much less run. :)

Ron Jeffries
ronjeffries.com<http://ronjeffries.com/>
Master your instrument, master the music, then forget all that shit and just play. -- Charlie Parker

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hi Michael,

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
I appreciate the responses. The best they are going to do now is heavy weighting to individuals who cause team success. It was a win for me just to have them let go of putting their initials on the task stickies for the purpose of getting individual credit. "Small moves, Ellie, small moves.” :)

I recall a coaching visit that James Grenning and I made to a large company out west. The manager told us in private that he really knew his team and that Jack (or whatever) was the team hero. In the meetings, Jack made it pretty clear that he was the team hero, controlling conversations, always knowing what to do next and so on.

When we met privately with the team they told us that Joe was the team hero, because Jack never finished anything and when he did, it didn’t work, and Joe was the one who made everything work.

So who caused “team success” on that team, Jack, or Joe? I know who I’d bet on, and the manager’s money was on the wrong horse.

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."

[MJ [e-mail] [SCRUMDEVELOPMENT]]

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
When we met privately with the team they told us that Joe was the team hero, because Jack never finished anything and when he did, it didn’t work, and Joe was the one who made everything work.
So who caused “team success” on that team, Jack, or Joe? I know who I’d bet on, and the manager’s money was on the wrong horse.

Related to Ron's concern, my concern with rewarding "teamwork" is that it will cause more looking good for the boss type behaviors. The best thing a boss could do to reduce the harm of performance appraisals is make it clear he's using completely random rankings, perhaps by rolling dice in front of everyone affected.

--mj

[[e-mail] [SCRUMDEVELOPMENT]]

I have to say, all the discussion on the "best" way to do performance appraisals in an agile environment is saddening in light of the fact that nearly all of the recent data indicates that performance appraisals have the exact opposite of the intended effect. I understand that change, especially in large companies, is hard. But maybe a better question is to figure how to move toward eliminating performance appraisals in such environments rather then how to make them "better?" Frankly the discussion smells like astrologists debating how to make more accurate predictions.

FWIW, The path my company is on is leading us to:
Elimination of management and all reporting structures Teams entirely self-managed Employees set their own salaries with consultation and advice from the team "Reviews" are team-based consultations about the things someone is doing well, and areas they could improve. (e.g. team member sits down with other team members and have an open, honest discussion; in effect a retrospective on the person's contributions to the team, and an opportunity for team members to coach each other). It has no impact on compensation. -Jeff

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

Jeff,

That’s all well and good, but unless you have magical powers, the best I can do for my larger clients is recommend something that will fit within the system they have.

Michael

Post by ***@gmail.com [SCRUMDEVELOPMENT]
I have to say, all the discussion on the "best" way to do performance appraisals in an agile environment is saddening in light of the fact that nearly all of the recent data indicates that performance appraisals have the exact opposite of the intended effect. I understand that change, especially in large companies, is hard. But maybe a better question is to figure how to move toward eliminating performance appraisals in such environments rather then how to make them "better?" Frankly the discussion smells like astrologists debating how to make more accurate predictions.
Elimination of management and all reporting structures
Teams entirely self-managed
Employees set their own salaries with consultation and advice from the team
"Reviews" are team-based consultations about the things someone is doing well, and areas they could improve. (e.g. team member sits down with other team members and have an open, honest discussion; in effect a retrospective on the person's contributions to the team, and an opportunity for team members to coach each other). It has no impact on compensation.
-Jeff

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

Try doubling your price. Then they'll either start listening to you or you
can go somewhere where they do. Worst case, they pay you double and still
aren't listening to you. In which case, repeat.

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Jeff,
That’s all well and good, but unless you have magical powers, the best I
can do for my larger clients is recommend something that will fit within
the system they have.
Michael
I have to say, all the discussion on the "best" way to do performance
appraisals in an agile environment is saddening in light of the fact that
nearly all of the recent data indicates that performance appraisals have
the exact opposite of the intended effect. I understand that change,
especially in large companies, is hard. But maybe a better question is to
figure how to move toward eliminating performance appraisals in such
environments rather then how to make them "better?" Frankly the discussion
smells like astrologists debating how to make more accurate predictions.
- Elimination of management and all reporting structures
- Teams entirely self-managed
- Employees set their own salaries with consultation and advice from
the team
- "Reviews" are team-based consultations about the things someone is
doing well, and areas they could improve. (e.g. team member sits down with
other team members and have an open, honest discussion; in effect a
retrospective on the person's contributions to the team, and an opportunity
for team members to coach each other). It has no impact on compensation.
-Jeff

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

I like your thinking, Adam.

Try doubling your price. Then they'll either start listening to you or you can go somewhere where they do. Worst case, they pay you double and still aren't listening to you. In which case, repeat.