Discussion:
[SCRUMDEVELOPMENT] Performance Reviews
Michael Wollin yahoo@mercurysw.com [SCRUMDEVELOPMENT]
2015-05-21 16:12:17 UTC
Permalink
Yeah. That.

Where can I read up on ideas that can be realistically proposed to my client about ways to compensate and evaluate agile developers? Eliminating performance reviews entirely would be really great, but not possible in the short term. So specifically, I’m looking for ways to still have performance reviews but
Avoid zero sum game pitting developers against one another
Not encourage documenting tasks done in order to get credit
Give managers some guidance on what to focus on

Can someone point me to articles with some gravitas (HBR, etc.)?

Thanks.

Michael
Mark Palmer markpalmer@gmail.com [SCRUMDEVELOPMENT]
2015-05-21 16:47:40 UTC
Permalink
I like Marcus Buckingham's article, "What if Performance Management Focused

on Strengths?" --
https://hbr.org/2013/12/what-if-performance-management-focused-on-strengths/
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. That.
Where can I read up on ideas that can be *realistically* proposed to my
client about ways to compensate and evaluate agile developers? Eliminating
performance reviews entirely would be really great, but not possible in the
short term. So specifically, I’m looking for ways to still have performance
reviews but
- Avoid zero sum game pitting developers against one another
- Not encourage documenting tasks done in order to get credit
- Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
George Dinwiddie lists@idiacomputing.com [SCRUMDEVELOPMENT]
2015-05-21 16:58:20 UTC
Permalink
Michael,

Who do you need to convince, and what would they consider authoritative
enough to overrule their existing beliefs?

- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. That.
Where can I read up on ideas that can be /realistically/ proposed to my
client about ways to compensate and evaluate agile developers?
Eliminating performance reviews entirely would be really great, but not
possible in the short term. So specifically, I’m looking for ways to
still have performance reviews but
* Avoid zero sum game pitting developers against one another
* Not encourage documenting tasks done in order to get credit
* Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Michael Wollin yahoo@mercurysw.com [SCRUMDEVELOPMENT]
2015-05-21 17:11:56 UTC
Permalink
I have some pull, George. I was trying to eliminate pointers to everyone’s overgeneralized blogs. I find that articles in HBR or from Deming, etc. have a rigor that allow me to be deeply grounded when I make my recommendations. Moreover a well written, peer reviewed or scholarly article does help support things. I have an opportunity to impact things. There is a window where leadership is looking for alternatives (within the constraints they too are under).
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Michael,
Who do you need to convince, and what would they consider authoritative
enough to overrule their existing beliefs?
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. That.
Where can I read up on ideas that can be /realistically/ proposed to my
client about ways to compensate and evaluate agile developers?
Eliminating performance reviews entirely would be really great, but not
possible in the short term. So specifically, I’m looking for ways to
still have performance reviews but
* Avoid zero sum game pitting developers against one another
* Not encourage documenting tasks done in order to get credit
* Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com <http://blog.gdinwiddie.com/>
Software Development http://www.idiacomputing.com <http://www.idiacomputing.com/>
Consultant and Coach http://www.agilemaryland.org <http://www.agilemaryland.org/>
----------------------------------------------------------
George Dinwiddie lists@idiacomputing.com [SCRUMDEVELOPMENT]
2015-05-21 17:20:33 UTC
Permalink
Michael,

OK, good luck. You're telling me what _you_ find convincing, not what
your client finds convincing. But you're already convinced.

You might ask Esther Derby for recommendations.

- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
I have some pull, George. I was trying to eliminate pointers to
everyone’s overgeneralized blogs. I find that articles in HBR or from
Deming, etc. have a rigor that allow me to be deeply grounded when I
make my recommendations. Moreover a well written, peer reviewed or
scholarly article does help support things. I have an opportunity to
impact things. There is a window where leadership is looking for
alternatives (within the constraints they too are under).
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Michael,
Who do you need to convince, and what would they consider authoritative
enough to overrule their existing beliefs?
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. That.
Where can I read up on ideas that can be /realistically/ proposed to my
client about ways to compensate and evaluate agile developers?
Eliminating performance reviews entirely would be really great, but not
possible in the short term. So specifically, I’m looking for ways to
still have performance reviews but
* Avoid zero sum game pitting developers against one another
* Not encourage documenting tasks done in order to get credit
* Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
--
----------------------------------------------------------
* George Dinwiddie *http://blog.gdinwiddie.com
<http://blog.gdinwiddie.com/>
Software Developmenthttp://www.idiacomputing.com
<http://www.idiacomputing.com/>
Consultant and Coachhttp://www.agilemaryland.org
<http://www.agilemaryland.org/>
----------------------------------------------------------
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Michael Wollin yahoo@mercurysw.com [SCRUMDEVELOPMENT]
2015-05-21 18:38:56 UTC
Permalink
George,

I’m looking for what would have me AND my client convinced to try something new, and inspect and adapt from there. The only thing I am convinced of is that the current system is failing them. The other thing I am convinced of is that I have to have my ducks in a row. How many of us ran to our managers in the 80s with copies of Peopleware hoping they’d read it and change?

- Michael
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Michael,
OK, good luck. You're telling me what _you_ find convincing, not what
your client finds convincing. But you're already convinced.
You might ask Esther Derby for recommendations.
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
I have some pull, George. I was trying to eliminate pointers to
everyone’s overgeneralized blogs. I find that articles in HBR or from
Deming, etc. have a rigor that allow me to be deeply grounded when I
make my recommendations. Moreover a well written, peer reviewed or
scholarly article does help support things. I have an opportunity to
impact things. There is a window where leadership is looking for
alternatives (within the constraints they too are under).
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Michael,
Who do you need to convince, and what would they consider authoritative
enough to overrule their existing beliefs?
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. That.
Where can I read up on ideas that can be /realistically/ proposed to my
client about ways to compensate and evaluate agile developers?
Eliminating performance reviews entirely would be really great, but not
possible in the short term. So specifically, I’m looking for ways to
still have performance reviews but
* Avoid zero sum game pitting developers against one another
* Not encourage documenting tasks done in order to get credit
* Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
--
----------------------------------------------------------
* George Dinwiddie *http://blog.gdinwiddie.com <http://blog.gdinwiddie.com/>
<http://blog.gdinwiddie.com/ <http://blog.gdinwiddie.com/>>
Software Developmenthttp://www.idiacomputing.com <developmenthttp://www.idiacomputing.com>
<http://www.idiacomputing.com/ <http://www.idiacomputing.com/>>
Consultant and Coachhttp://www.agilemaryland.org <coachhttp://www.agilemaryland.org>
<http://www.agilemaryland.org/ <http://www.agilemaryland.org/>>
----------------------------------------------------------
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com <http://blog.gdinwiddie.com/>
Software Development http://www.idiacomputing.com <http://www.idiacomputing.com/>
Consultant and Coach http://www.agilemaryland.org <http://www.agilemaryland.org/>
----------------------------------------------------------
George Dinwiddie lists@idiacomputing.com [SCRUMDEVELOPMENT]
2015-05-22 03:10:17 UTC
Permalink
Michael,
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
George,
I’m looking for what would have me AND my client convinced to try
something new, and inspect and adapt from there. The only thing I am
convinced of is that the current system is failing them. The other thing
I am convinced of is that I have to have my ducks in a row. How many of
us ran to our managers in the 80s with copies of Peopleware hoping
they’d read it and change?
Did that work for you? I find change a bit harder than that. I'd suggest
starting with talking with those who have the power to make drop or
drastically change performance reviews. Find out what they think about
them--especially what problem they solve for them. What is it that they
would absolutely want to preserve if they made a change?

Without knowing that, I think you're shooting in the dark.

- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
- Michael
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Michael,
OK, good luck. You're telling me what _you_ find convincing, not what
your client finds convincing. But you're already convinced.
You might ask Esther Derby for recommendations.
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
I have some pull, George. I was trying to eliminate pointers to
everyone’s overgeneralized blogs. I find that articles in HBR or from
Deming, etc. have a rigor that allow me to be deeply grounded when I
make my recommendations. Moreover a well written, peer reviewed or
scholarly article does help support things. I have an opportunity to
impact things. There is a window where leadership is looking for
alternatives (within the constraints they too are under).
On May 21, 2015, at 11:58 AM, George
Michael,
Who do you need to convince, and what would they consider authoritative
enough to overrule their existing beliefs?
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. That.
Where can I read up on ideas that can be /realistically/ proposed
to my
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
client about ways to compensate and evaluate agile developers?
Eliminating performance reviews entirely would be really great,
but not
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
possible in the short term. So specifically, I’m looking for ways to
still have performance reviews but
* Avoid zero sum game pitting developers against one another
* Not encourage documenting tasks done in order to get credit
* Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
--
----------------------------------------------------------
* George Dinwiddie *http://blog.gdinwiddie.com
<http://blog.gdinwiddie.com/>
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
<http://blog.gdinwiddie.com/>
SoftwareDevelopmenthttp://www.idiacomputing.com
<developmenthttp://www.idiacomputing.com>
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
<http://www.idiacomputing.com/>
Consultant andCoachhttp://www.agilemaryland.org
<coachhttp://www.agilemaryland.org>
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
<http://www.agilemaryland.org/>
----------------------------------------------------------
--
----------------------------------------------------------
* George Dinwiddie *http://blog.gdinwiddie.com
<http://blog.gdinwiddie.com/>
Software Developmenthttp://www.idiacomputing.com
<http://www.idiacomputing.com/>
Consultant and Coachhttp://www.agilemaryland.org
<http://www.agilemaryland.org/>
----------------------------------------------------------
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Michael James mj4scrum@gmail.com [SCRUMDEVELOPMENT]
2015-05-22 05:42:31 UTC
Permalink
I’m also interested in practical suggestions, as clients have asked me about this. The first team I did Scrum in didn’t have an HR department, performance appraisals, and all the harmful things those things entails. Once that stuff is established, it seems harder to remove it (though Adobe has take steps in that direction).

A few years ago I attended a session at a Scrum gathering about how to make performance appraisals more effective in an Agile environment. If we believe performance appraisals are harmful, this idea is misguided. If the effect of performance appraisals is harmful, we should be working to render them as *ineffective* as possible. Sabotage them. For example, if I’m a supervisor who’s been told to stack rank my subordinates, I might go to the HR department and roll dice in full view of everyone.

I’ve reserved the domain name http://www.sabotageperformanceappraisals.org , but too lazy to set anything up there. Would anyone like to help me with graphics?

—mj
(Michael)
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Michael,
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
George,
I’m looking for what would have me AND my client convinced to try
something new, and inspect and adapt from there. The only thing I am
convinced of is that the current system is failing them. The other thing
I am convinced of is that I have to have my ducks in a row. How many of
us ran to our managers in the 80s with copies of Peopleware hoping
they’d read it and change?
Did that work for you? I find change a bit harder than that. I'd suggest
starting with talking with those who have the power to make drop or
drastically change performance reviews. Find out what they think about
them--especially what problem they solve for them. What is it that they
would absolutely want to preserve if they made a change?
Without knowing that, I think you're shooting in the dark.
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
- Michael
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Michael,
OK, good luck. You're telling me what _you_ find convincing, not what
your client finds convincing. But you're already convinced.
You might ask Esther Derby for recommendations.
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
I have some pull, George. I was trying to eliminate pointers to
everyone’s overgeneralized blogs. I find that articles in HBR or from
Deming, etc. have a rigor that allow me to be deeply grounded when I
make my recommendations. Moreover a well written, peer reviewed or
scholarly article does help support things. I have an opportunity to
impact things. There is a window where leadership is looking for
alternatives (within the constraints they too are under).
On May 21, 2015, at 11:58 AM, George
Michael,
Who do you need to convince, and what would they consider authoritative
enough to overrule their existing beliefs?
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. That.
Where can I read up on ideas that can be /realistically/ proposed
to my
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
client about ways to compensate and evaluate agile developers?
Eliminating performance reviews entirely would be really great,
but not
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
possible in the short term. So specifically, I’m looking for ways to
still have performance reviews but
* Avoid zero sum game pitting developers against one another
* Not encourage documenting tasks done in order to get credit
* Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
--
----------------------------------------------------------
* George Dinwiddie *http://blog.gdinwiddie.com <http://blog.gdinwiddie.com/>
<http://blog.gdinwiddie.com/ <http://blog.gdinwiddie.com/>>
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
<http://blog.gdinwiddie.com/ <http://blog.gdinwiddie.com/>>
SoftwareDevelopmenthttp://www.idiacomputing.com <softwaredevelopmenthttp://www.idiacomputing.com>
<developmenthttp://www.idiacomputing.com <developmenthttp://www.idiacomputing.com>>
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
<http://www.idiacomputing.com/ <http://www.idiacomputing.com/>>
Consultant andCoachhttp://www.agilemaryland.org <andcoachhttp://www.agilemaryland.org>
<coachhttp://www.agilemaryland.org <coachhttp://www.agilemaryland.org>>
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
<http://www.agilemaryland.org/ <http://www.agilemaryland.org/>>
----------------------------------------------------------
--
----------------------------------------------------------
* George Dinwiddie *http://blog.gdinwiddie.com <http://blog.gdinwiddie.com/>
<http://blog.gdinwiddie.com/ <http://blog.gdinwiddie.com/>>
Software Developmenthttp://www.idiacomputing.com <developmenthttp://www.idiacomputing.com>
<http://www.idiacomputing.com/ <http://www.idiacomputing.com/>>
Consultant and Coachhttp://www.agilemaryland.org <coachhttp://www.agilemaryland.org>
<http://www.agilemaryland.org/ <http://www.agilemaryland.org/>>
----------------------------------------------------------
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com <http://blog.gdinwiddie.com/>
Software Development http://www.idiacomputing.com <http://www.idiacomputing.com/>
Consultant and Coach http://www.agilemaryland.org <http://www.agilemaryland.org/>
----------------------------------------------------------
Yves Hanoulle mailing@hanoulle.be [SCRUMDEVELOPMENT]
2015-05-22 09:28:35 UTC
Permalink
Post by Michael James ***@gmail.com [SCRUMDEVELOPMENT]
I’m also interested in practical suggestions, as clients have asked me
about this. The first team I did Scrum in didn’t have an HR department,
performance appraisals, and all the harmful things those things entails.
Once that stuff is established, it seems harder to remove it (though Adobe
has take steps in that direction).
A few years ago I attended a session at a Scrum gathering about how to
make performance appraisals more effective in an Agile environment. If we
believe performance appraisals are harmful, this idea is misguided. If the
effect of performance appraisals is harmful, we should be working to render
them as *ineffective* as possible. Sabotage them.
I disagree, the way companies that use PV are set up , you will loose
For example, if I’m a supervisor who’s been told to stack rank my
subordinates, I might go to the HR department and roll dice in full view of
everyone.
They will blame you , as it's your job (according To them) and might fire
you On tje spot.
Although That is probably ok for most people On this list, (At least I
hope)


Yet it does not help to make the effects of PV be visible
Post by Michael James ***@gmail.com [SCRUMDEVELOPMENT]
I’ve reserved the domain name http://www.sabotageperformanceappraisals.org
, but too lazy to set anything up there. Would anyone like to help me with
graphics?
—mj
(Michael)
Michael,
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
George,
I’m looking for what would have me AND my client convinced to try
something new, and inspect and adapt from there. The only thing I am
convinced of is that the current system is failing them. The other thing
I am convinced of is that I have to have my ducks in a row. How many of
us ran to our managers in the 80s with copies of Peopleware hoping
they’d read it and change?
Did that work for you? I find change a bit harder than that. I'd suggest
starting with talking with those who have the power to make drop or
drastically change performance reviews. Find out what they think about
them--especially what problem they solve for them. What is it that they
would absolutely want to preserve if they made a change?
Without knowing that, I think you're shooting in the dark.
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
- Michael
[SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Michael,
OK, good luck. You're telling me what _you_ find convincing, not what
your client finds convincing. But you're already convinced.
You might ask Esther Derby for recommendations.
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
I have some pull, George. I was trying to eliminate pointers to
everyone’s overgeneralized blogs. I find that articles in HBR or from
Deming, etc. have a rigor that allow me to be deeply grounded when I
make my recommendations. Moreover a well written, peer reviewed or
scholarly article does help support things. I have an opportunity to
impact things. There is a window where leadership is looking for
alternatives (within the constraints they too are under).
On May 21, 2015, at 11:58 AM, George
[SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Michael,
Who do you need to convince, and what would they consider
authoritative
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
enough to overrule their existing beliefs?
- George
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. That.
Where can I read up on ideas that can be /realistically/ proposed
to my
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
client about ways to compensate and evaluate agile developers?
Eliminating performance reviews entirely would be really great,
but not
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
possible in the short term. So specifically, I’m looking for ways
to
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
still have performance reviews but
* Avoid zero sum game pitting developers against one another
* Not encourage documenting tasks done in order to get credit
* Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
--
----------------------------------------------------------
* George Dinwiddie *http://blog.gdinwiddie.com
<http://blog.gdinwiddie.com/>
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
<http://blog.gdinwiddie.com/>
SoftwareDevelopmenthttp://www.idiacomputing.com
<developmenthttp://www.idiacomputing.com>
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
<http://www.idiacomputing.com/>
Consultant andCoachhttp://www.agilemaryland.org
<coachhttp://www.agilemaryland.org>
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
<http://www.agilemaryland.org/>
----------------------------------------------------------
--
----------------------------------------------------------
* George Dinwiddie *http://blog.gdinwiddie.com
<http://blog.gdinwiddie.com/>
Software Developmenthttp://www.idiacomputing.com
<http://www.idiacomputing.com/>
Consultant and Coachhttp://www.agilemaryland.org
<http://www.agilemaryland.org/>
----------------------------------------------------------
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------
--
Yves Hanoulle
Phone 00 32 467 43 38 32


Skype YvesHanoulle


Blog: www.Hanoulle.be <http://www.hanoulle.be/>


Coaching Question Of the Day: http://twitter.com/Retroflection
Yves Hanoulle mailing@hanoulle.be [SCRUMDEVELOPMENT]
2015-05-21 17:09:37 UTC
Permalink
do the performance review on team level, instead of team member level
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. That.
Where can I read up on ideas that can be *realistically* proposed to my
client about ways to compensate and evaluate agile developers? Eliminating
performance reviews entirely would be really great, but not possible in the
short term. So specifically, I’m looking for ways to still have performance
reviews but
- Avoid zero sum game pitting developers against one another
- Not encourage documenting tasks done in order to get credit
- Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
--
Yves Hanoulle
Phone 00 32 467 43 38 32


Skype YvesHanoulle


Blog: www.Hanoulle.be <http://www.hanoulle.be/>


Coaching Question Of the Day: http://twitter.com/Retroflection
Natarajan Kalpathy Natarajan_Kalpathy@yahoo.com [SCRUMDEVELOPMENT]
2015-05-21 18:33:53 UTC
Permalink
I have had similar problems with performance appraisals in my team and I like the team based performance reviews/appraisal idea. My problem is that its very difficult to change HR/Company mindset which is still hell bent on doing bell curve based ratings of each developer.
The biggest resistance I have heard from HR is1) How to you identify leaders who can take up more responsibilities.2) How to you handle developers who are not pulling their weight.
My answer to that has been the team should have the motivation to push out bad developers and usually managers who are really plugged into their team (e.g. a chicken role in daily standup or just observations through experience) can identify leaders who are not only able to do their own work but help team members get better in doing their jobs.
This answer has not convinced HR so far. I obviously don't want to throw stats such has who has done how many user stories etc  because that's just anti agile and its very hard to measure some of the subjective stuff. At the same time Managers have hard time convincing HR/Company on some of the above ideas.
I am also eagerly anticipating on what others in the group here have to say.
-Natarajan


From: "Yves Hanoulle ***@hanoulle.be [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Thursday, May 21, 2015 10:39 PM
Subject: Re: [SCRUMDEVELOPMENT] Performance Reviews

  do the performance review on team level, instead of team member level
2015-05-21 18:12 GMT+02:00 Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT] <***@yahoogroups.com>:


  Yeah. That. 
Where can I read up on ideas that can be realistically proposed to my client about ways to compensate and evaluate agile developers? Eliminating performance reviews entirely would be really great, but not possible in the short term. So specifically, I’m looking for ways to still have performance reviews but  
- Avoid zero sum game pitting developers against one another 
- Not encourage documenting tasks done in order to get credit
- Give managers some guidance on what to focus on


Can someone point me to articles with some gravitas (HBR, etc.)? 
Thanks. 
Michael
--
Yves Hanoulle 
Phone 00 32 467 43 38 32Skype YvesHanoulleBlog: www.Hanoulle.beCoaching Question Of the Day: http://twitter.com/Retroflection #yiv9081263582 #yiv9081263582 -- #yiv9081263582ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9081263582 #yiv9081263582ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9081263582 #yiv9081263582ygrp-mkp #yiv9081263582hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv9081263582 #yiv9081263582ygrp-mkp #yiv9081263582ads {margin-bottom:10px;}#yiv9081263582 #yiv9081263582ygrp-mkp .yiv9081263582ad {padding:0 0;}#yiv9081263582 #yiv9081263582ygrp-mkp .yiv9081263582ad p {margin:0;}#yiv9081263582 #yiv9081263582ygrp-mkp .yiv9081263582ad a {color:#0000ff;text-decoration:none;}#yiv9081263582 #yiv9081263582ygrp-sponsor #yiv9081263582ygrp-lc {font-family:Arial;}#yiv9081263582 #yiv9081263582ygrp-sponsor #yiv9081263582ygrp-lc #yiv9081263582hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9081263582 #yiv9081263582ygrp-sponsor #yiv9081263582ygrp-lc .yiv9081263582ad {margin-bottom:10px;padding:0 0;}#yiv9081263582 #yiv9081263582actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9081263582 #yiv9081263582activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9081263582 #yiv9081263582activity span {font-weight:700;}#yiv9081263582 #yiv9081263582activity span:first-child {text-transform:uppercase;}#yiv9081263582 #yiv9081263582activity span a {color:#5085b6;text-decoration:none;}#yiv9081263582 #yiv9081263582activity span span {color:#ff7900;}#yiv9081263582 #yiv9081263582activity span .yiv9081263582underline {text-decoration:underline;}#yiv9081263582 .yiv9081263582attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv9081263582 .yiv9081263582attach div a {text-decoration:none;}#yiv9081263582 .yiv9081263582attach img {border:none;padding-right:5px;}#yiv9081263582 .yiv9081263582attach label {display:block;margin-bottom:5px;}#yiv9081263582 .yiv9081263582attach label a {text-decoration:none;}#yiv9081263582 blockquote {margin:0 0 0 4px;}#yiv9081263582 .yiv9081263582bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv9081263582 .yiv9081263582bold a {text-decoration:none;}#yiv9081263582 dd.yiv9081263582last p a {font-family:Verdana;font-weight:700;}#yiv9081263582 dd.yiv9081263582last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9081263582 dd.yiv9081263582last p span.yiv9081263582yshortcuts {margin-right:0;}#yiv9081263582 div.yiv9081263582attach-table div div a {text-decoration:none;}#yiv9081263582 div.yiv9081263582attach-table {width:400px;}#yiv9081263582 div.yiv9081263582file-title a, #yiv9081263582 div.yiv9081263582file-title a:active, #yiv9081263582 div.yiv9081263582file-title a:hover, #yiv9081263582 div.yiv9081263582file-title a:visited {text-decoration:none;}#yiv9081263582 div.yiv9081263582photo-title a, #yiv9081263582 div.yiv9081263582photo-title a:active, #yiv9081263582 div.yiv9081263582photo-title a:hover, #yiv9081263582 div.yiv9081263582photo-title a:visited {text-decoration:none;}#yiv9081263582 div#yiv9081263582ygrp-mlmsg #yiv9081263582ygrp-msg p a span.yiv9081263582yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9081263582 .yiv9081263582green {color:#628c2a;}#yiv9081263582 .yiv9081263582MsoNormal {margin:0 0 0 0;}#yiv9081263582 o {font-size:0;}#yiv9081263582 #yiv9081263582photos div {float:left;width:72px;}#yiv9081263582 #yiv9081263582photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv9081263582 #yiv9081263582photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9081263582 #yiv9081263582reco-category {font-size:77%;}#yiv9081263582 #yiv9081263582reco-desc {font-size:77%;}#yiv9081263582 .yiv9081263582replbq {margin:4px;}#yiv9081263582 #yiv9081263582ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv9081263582 #yiv9081263582ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv9081263582 #yiv9081263582ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv9081263582 #yiv9081263582ygrp-mlmsg select, #yiv9081263582 input, #yiv9081263582 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv9081263582 #yiv9081263582ygrp-mlmsg pre, #yiv9081263582 code {font:115% monospace;}#yiv9081263582 #yiv9081263582ygrp-mlmsg * {line-height:1.22em;}#yiv9081263582 #yiv9081263582ygrp-mlmsg #yiv9081263582logo {padding-bottom:10px;}#yiv9081263582 #yiv9081263582ygrp-msg p a {font-family:Verdana;}#yiv9081263582 #yiv9081263582ygrp-msg p#yiv9081263582attach-count span {color:#1E66AE;font-weight:700;}#yiv9081263582 #yiv9081263582ygrp-reco #yiv9081263582reco-head {color:#ff7900;font-weight:700;}#yiv9081263582 #yiv9081263582ygrp-reco {margin-bottom:20px;padding:0px;}#yiv9081263582 #yiv9081263582ygrp-sponsor #yiv9081263582ov li a {font-size:130%;text-decoration:none;}#yiv9081263582 #yiv9081263582ygrp-sponsor #yiv9081263582ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv9081263582 #yiv9081263582ygrp-sponsor #yiv9081263582ov ul {margin:0;padding:0 0 0 8px;}#yiv9081263582 #yiv9081263582ygrp-text {font-family:Georgia;}#yiv9081263582 #yiv9081263582ygrp-text p {margin:0 0 1em 0;}#yiv9081263582 #yiv9081263582ygrp-text tt {font-size:120%;}#yiv9081263582 #yiv9081263582ygrp-vital ul li:last-child {border-right:none !important;}#yiv9081263582
Eric Gunnerson Eric.Gunnerson@microsoft.com [SCRUMDEVELOPMENT]
2015-05-21 22:11:24 UTC
Permalink
I like the idea of team-based over individual based, but I’m wondering if you might see gaming and reduced cooperation at the team level instead of at the individual level.

Does anybody have any experience with team-based rewards?

From: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Thursday, May 21, 2015 11:34 AM
To: ***@yahoogroups.com
Subject: Re: [SCRUMDEVELOPMENT] Performance Reviews


I have had similar problems with performance appraisals in my team and I like the team based performance reviews/appraisal idea. My problem is that its very difficult to change HR/Company mindset which is still hell bent on doing bell curve based ratings of each developer.

The biggest resistance I have heard from HR is
1) How to you identify leaders who can take up more responsibilities.
2) How to you handle developers who are not pulling their weight.

My answer to that has been the team should have the motivation to push out bad developers and usually managers who are really plugged into their team (e.g. a chicken role in daily standup or just observations through experience) can identify leaders who are not only able to do their own work but help team members get better in doing their jobs.

This answer has not convinced HR so far. I obviously don't want to throw stats such has who has done how many user stories etc because that's just anti agile and its very hard to measure some of the subjective stuff. At the same time Managers have hard time convincing HR/Company on some of the above ideas.

I am also eagerly anticipating on what others in the group here have to say.

-Natarajan

________________________________
From: "Yves Hanoulle ***@hanoulle.be [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Thursday, May 21, 2015 10:39 PM
Subject: Re: [SCRUMDEVELOPMENT] Performance Reviews


do the performance review on team level, instead of team member level

2015-05-21 18:12 GMT+02:00 Michael Wollin ***@mercurysw.com<mailto:***@mercurysw.com> [SCRUMDEVELOPMENT] <***@yahoogroups.com<mailto:***@yahoogroups.com>>:

Yeah. That.

Where can I read up on ideas that can be realistically proposed to my client about ways to compensate and evaluate agile developers? Eliminating performance reviews entirely would be really great, but not possible in the short term. So specifically, I’m looking for ways to still have performance reviews but

* Avoid zero sum game pitting developers against one another
* Not encourage documenting tasks done in order to get credit
* Give managers some guidance on what to focus on

Can someone point me to articles with some gravitas (HBR, etc.)?

Thanks.

Michael
--
Yves Hanoulle
Phone 00 32 467 43 38 32
Skype YvesHanoulle
Blog: www.Hanoulle.be<http://www.hanoulle.be/>
Coaching Question Of the Day: http://twitter.com/Retroflection
Ron Jeffries ronjeffries@acm.org [SCRUMDEVELOPMENT]
2015-05-21 22:27:51 UTC
Permalink
Wouldn’t team-based gaming reduce the gamer’s rating?
Post by Eric Gunnerson ***@microsoft.com [SCRUMDEVELOPMENT]
I like the idea of team-based over individual based, but I’m wondering if you might see gaming and reduced cooperation at the team level instead of at the individual level.
Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana
Eric Gunnerson Eric.Gunnerson@microsoft.com [SCRUMDEVELOPMENT]
2015-05-22 16:49:30 UTC
Permalink
I think I wasn’t clear in what I was saying


By “team-based”, I meant that teams are rated instead of individuals. If you have multiple teams, that means that you are going to be rating teams against each other. I think this situation is probably worse from a gaming perspective; in a single agile team the individuals depend on each other so there is social pressure against me trying to unfairly look better than my teammates.

I’m not sure what team measurements would be used, but I my guess is that they will set up the wrong incentives. If, for example, you counted story points, you’d see story point inflation. If you counted features, you will see some teams feel they got treated unfairly because they ended up with the harder and less-flashier features.

I also expect that I will see teams to de-emphasize activities that are “low-value-add” to the metrics – things like helping other teams improve, keeping technical debt low, that sort of thing.


From: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Thursday, May 21, 2015 3:28 PM
To: ***@yahoogroups.com
Subject: Re: [SCRUMDEVELOPMENT] Performance Reviews



Wouldn’t team-based gaming reduce the gamer’s rating?

On May 21, 2015, at 6:11 PM, Eric Gunnerson ***@microsoft.com<mailto:***@microsoft.com> [SCRUMDEVELOPMENT] <***@yahoogroups.com<mailto:***@yahoogroups.com>> wrote:

I like the idea of team-based over individual based, but I’m wondering if you might see gaming and reduced cooperation at the team level instead of at the individual level.


Ron Jeffries
ronjeffries.com<http://ronjeffries.com>
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana
Yves Hanoulle mailing@hanoulle.be [SCRUMDEVELOPMENT]
2015-05-22 19:53:44 UTC
Permalink
Post by Eric Gunnerson ***@microsoft.com [SCRUMDEVELOPMENT]
I think I wasn’t clear in what I was saying

By “team-based”, I meant that teams are rated instead of individuals. If
you have multiple teams, that means that you are going to be rating teams
against each other. I think this situation is probably worse from a gaming
perspective; in a single agile team the individuals depend on each other so
there is social pressure against me trying to unfairly look better than my
teammates.
I’m not sure what team measurements would be used, but I my guess is that
they will set up the wrong incentives.
that is a harsh statement
what would a team that is going for a better way of working choose for bad
incentives?


one of the teams I know that used this: had a KPI on helping each other


another on how good everyone knew all the code and were able to do all the
work independent of who was in...
Post by Eric Gunnerson ***@microsoft.com [SCRUMDEVELOPMENT]
If, for example, you counted story points, you’d see story point
inflation. If you counted features, you will see some teams feel they got
treated unfairly because they ended up with the harder and less-flashier
features.
I also expect that I will see teams to de-emphasize activities that are
“low-value-add” to the metrics – things like helping other teams improve,
keeping technical debt low, that sort of thing.
*Sent:* Thursday, May 21, 2015 3:28 PM
*Subject:* Re: [SCRUMDEVELOPMENT] Performance Reviews
Wouldn’t team-based gaming reduce the gamer’s rating?
I like the idea of team-based over individual based, but I’m wondering if
you might see gaming and reduced cooperation at the team level instead of
at the individual level.
Ron Jeffries
ronjeffries.com
Before you contradict an old man, my fair friend, you should endeavor to
understand him. - George Santayana
--
Yves Hanoulle
Phone 00 32 467 43 38 32


Skype YvesHanoulle


Blog: www.Hanoulle.be <http://www.hanoulle.be/>


Coaching Question Of the Day: http://twitter.com/Retroflection
Yves Hanoulle mailing@hanoulle.be [SCRUMDEVELOPMENT]
2015-05-21 22:58:50 UTC
Permalink
Post by Eric Gunnerson ***@microsoft.com [SCRUMDEVELOPMENT]
I like the idea of team-based over individual based, but I’m wondering
if you might see gaming and reduced cooperation at the team level instead
of at the individual level.
I'm not sure what you mean.
would teams not work together?


could be, yet I see already so many teams not collaborating, that it
usually is hard to see if it gets worse.


that said, as it solves the personal issues, you will get better
collaboration inside the team
this itself is already wurth it


y
Post by Eric Gunnerson ***@microsoft.com [SCRUMDEVELOPMENT]
Does anybody have any experience with team-based rewards?
*Sent:* Thursday, May 21, 2015 11:34 AM
*Subject:* Re: [SCRUMDEVELOPMENT] Performance Reviews
I have had similar problems with performance appraisals in my team and I
like the team based performance reviews/appraisal idea. My problem is that
its very difficult to change HR/Company mindset which is still hell bent on
doing bell curve based ratings of each developer.
The biggest resistance I have heard from HR is
1) How to you identify leaders who can take up more responsibilities.
2) How to you handle developers who are not pulling their weight.
My answer to that has been the team should have the motivation to push out
bad developers and usually managers who are really plugged into their team
(e.g. a chicken role in daily standup or just observations through
experience) can identify leaders who are not only able to do their own work
but help team members get better in doing their jobs.
This answer has not convinced HR so far. I obviously don't want to throw
stats such has who has done how many user stories etc because that's just
anti agile and its very hard to measure some of the subjective stuff. At
the same time Managers have hard time convincing HR/Company on some of the
above ideas.
I am also eagerly anticipating on what others in the group here have to say.
-Natarajan
------------------------------
*Sent:* Thursday, May 21, 2015 10:39 PM
*Subject:* Re: [SCRUMDEVELOPMENT] Performance Reviews
do the performance review on team level, instead of team member level
Yeah. That.
Where can I read up on ideas that can be *realistically* proposed to my
client about ways to compensate and evaluate agile developers? Eliminating
performance reviews entirely would be really great, but not possible in the
short term. So specifically, I’m looking for ways to still have performance
reviews but
- Avoid zero sum game pitting developers against one another
- Not encourage documenting tasks done in order to get credit
- Give managers some guidance on what to focus on
Can someone point me to articles with some gravitas (HBR, etc.)?
Thanks.
Michael
--
Yves Hanoulle
Phone 00 32 467 43 38 32
Skype YvesHanoulle
Blog: www.Hanoulle.be <http://www.hanoulle.be/>
Coaching Question Of the Day: http://twitter.com/Retroflection
--
Yves Hanoulle
Phone 00 32 467 43 38 32


Skype YvesHanoulle


Blog: www.Hanoulle.be <http://www.hanoulle.be/>


Coaching Question Of the Day: http://twitter.com/Retroflection
Charles Bradley - Professional Scrum Trainer and Coach chuck-lists2@emailchuck.com [SCRUMDEVELOPMENT]
2015-05-22 07:08:20 UTC
Permalink
I've always liked Jeff Sutherland's Perf Review approach:http://www.scruminc.com/agile-performance-reviews/

And Google has an interesting view on developer pay.  :-)http://www.businessinsider.com/google-policy-to-pay-unfairly-2015-4 -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Thursday, May 21, 2015 10:12 AM
Subject: [SCRUMDEVELOPMENT] Performance Reviews

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

Yeah. That. 
Where can I read up on ideas that can be realistically proposed to my client about ways to compensate and evaluate agile developers? Eliminating performance reviews entirely would be really great, but not possible in the short term. So specifically, I’m looking for ways to still have performance reviews but  
- Avoid zero sum game pitting developers against one another 
- Not encourage documenting tasks done in order to get credit
- Give managers some guidance on what to focus on

Can someone point me to articles with some gravitas (HBR, etc.)? 
Thanks. 
Michael
Ron Jeffries ronjeffries@acm.org [SCRUMDEVELOPMENT]
2015-05-22 07:52:17 UTC
Permalink
Charles,
http://www.scruminc.com/agile-performance-reviews/ <http://www.scruminc.com/agile-performance-reviews/>
I note in that article that it seems to switch between paragraphs between the review being about the employee and a reviewer, and in the next, the team is giving a rating. It seems there must be something missing or erroneous in the article.

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Perfectionism is the voice of the oppressor -- Anne Lamott
Charles Bradley - Professional Scrum Trainer and Coach chuck-lists2@emailchuck.com [SCRUMDEVELOPMENT]
2015-05-27 01:51:58 UTC
Permalink
Ron,
I'm not seeing what you're talking about.  Can you be more specific?
 -------
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: Friday, May 22, 2015 1:52 AM
Subject: Re: [SCRUMDEVELOPMENT] Performance Reviews

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

Charles,

On May 22, 2015, at 3:08 AM, Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:
I've always liked Jeff Sutherland's Perf Review approach:http://www.scruminc.com/agile-performance-reviews/

I note in that article that it seems to switch between paragraphs between the review being about the employee and a reviewer, and in the next, the team is giving a rating. It seems there must be something missing or erroneous in the article.

Ron Jeffriesronjeffries.comPerfectionism is the voice of the oppressor -- Anne Lamott
Ron Jeffries ronjeffries@acm.org [SCRUMDEVELOPMENT]
2015-05-31 22:06:29 UTC
Permalink
Hi Charles,
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 Jeffries
ronjeffries.com <http://ronjeffries.com/>
If not now, when? -- Rabbi Hillel
Cipson cipson@gmail.com [SCRUMDEVELOPMENT]
2015-06-02 16:57:38 UTC
Permalink
Win win situation for team and individual.

With my experience, 50% team performance and 50% individual peformacne have
better balance.

Regards
Cipson Thomas

***@gmail.com || +91 8606 55 77 99 (Mobile)
<http://meninweb.blogspot.com> <http://www.flickr.com/photos/meninweb>
Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
Hi Charles,
On May 26, 2015, at 9:51 PM, Charles Bradley - Professional Scrum Trainer
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.
1. Employee rates self;
2. Employee and reviewer discuss ratings;
3. Reviewer rates employee;
4. *Employee rating stands.*
At this moment the reader is all *WTF, the employee rating stands??*.
What follows doesn’t help alleviate the WTF.
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 Jeffries
ronjeffries.com
If not now, when? -- Rabbi Hillel
Yves Hanoulle mailing@hanoulle.be [SCRUMDEVELOPMENT]
2015-06-02 17:32:36 UTC
Permalink
what advantage does a (article) personal performance bring to you?


I try to understand, because eso far I have not seen one.


y
Post by Cipson ***@gmail.com [SCRUMDEVELOPMENT]
Win win situation for team and individual.
With my experience, 50% team performance and 50% individual peformacne
have better balance.
Regards
Cipson Thomas
<http://meninweb.blogspot.com> <http://www.flickr.com/photos/meninweb>
Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
Hi Charles,
On May 26, 2015, at 9:51 PM, Charles Bradley - Professional Scrum Trainer
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.
1. Employee rates self;
2. Employee and reviewer discuss ratings;
3. Reviewer rates employee;
4. *Employee rating stands.*
At this moment the reader is all *WTF, the employee rating stands??*.
What follows doesn’t help alleviate the WTF.
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 Jeffries
ronjeffries.com
If not now, when? -- Rabbi Hillel
--
Yves Hanoulle
Phone 00 32 467 43 38 32


Skype YvesHanoulle


Blog: www.Hanoulle.be <http://www.hanoulle.be/>


Coaching Question Of the Day: http://twitter.com/Retroflection
MJ mj4scrum@gmail.com [SCRUMDEVELOPMENT]
2015-06-02 17:35:33 UTC
Permalink
Cipson,

Are you saying that performance appraisals are a good thing? Do you have evidence of that?

--mj
(Michael James)
Post by Cipson ***@gmail.com [SCRUMDEVELOPMENT]
Win win situation for team and individual.
With my experience, 50% team performance and 50% individual peformacne have better balance.
Regards
Cipson Thomas
Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
Hi Charles,
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.
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.
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 Jeffries
ronjeffries.com
If not now, when? -- Rabbi Hillel
Pierre Neis pierreneis@gmail.com [SCRUMDEVELOPMENT]
2015-06-02 17:42:59 UTC
Permalink
so, a chicken can rate a pig to be more chicken?




Pierre*NEIS*


Lean Agile Coach | Associate


M: +352 / 661 727 867


***@wecompany.me


Luxembourg | Paris | Brussels | Geneva | Beirut


<https://pierreneis.youcanbook.me/>



*Next Conferences:*




- June 24-25th, Paris, BAFS, http://www.bafs2015.org/
- June 29-30th, Geneva, BAFS, http://www.bafs2015.org/
- Sept 11-13th, London, #play14London, http://london.play14.org/
Post by MJ ***@gmail.com [SCRUMDEVELOPMENT]
Cipson,
Are you saying that performance appraisals are a good thing? Do you have evidence of that?
--mj
(Michael James)
Win win situation for team and individual.
With my experience, 50% team performance and 50% individual peformacne have better balance.
Regards
Cipson Thomas
<http://meninweb.blogspot.com> <http://www.flickr.com/photos/meninweb>
Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
Hi Charles,
On May 26, 2015, at 9:51 PM, Charles Bradley - Professional Scrum Trainer
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.
1. Employee rates self;
2. Employee and reviewer discuss ratings;
3. Reviewer rates employee;
4. *Employee rating stands.*
At this moment the reader is all *WTF, the employee rating stands??*.
What follows doesn’t help alleviate the WTF.
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 Jeffries
ronjeffries.com
If not now, when? -- Rabbi Hillel
Stephen Starkey firepoet78@yahoo.com [SCRUMDEVELOPMENT]
2015-05-22 11:00:36 UTC
Permalink
What an interesting thread! For individual performance improvement we use this approach that I wrote about last year at my company and it is very well-received (the feedback people receive from their peers is generally accepted and with gratitude):


http://bit.ly/cl-feedforward


Also, when I first started I was the manager (now I'm the agile coach), and I took the radical step of simply refusing to participate. We have a bonus plan that is based on company performance -- each department receives enough cash to pay out a percentage of everyone's salary and the head of that department can allocate it how they want. So I said pay everyone at 100% of their allocation.


There was a brief hot moment, but I shared with them how hard it is to pin down individual performance and what it does to team cohesion and they backed down. It also helped to build up a relationship with executives and a lot of transparency so they could see how much better the environment was than before I worked there, so they trusted my judgment.


I have in the past used these articles:


http://www.strategy-business.com/article/00275?gko=c442b


http://gojko.net/2008/08/07/paying-programmers-are-bonuses-bad-and-what-to-do-about-it


Hope this helps!


Stephen Starkey
empathy | connectedness | restorative | relator | belief
http://coreagile.co/coaching


Sent from my iPad
Michael James mj4scrum@gmail.com [SCRUMDEVELOPMENT]
2015-05-22 14:13:04 UTC
Permalink
That’s a great story. Here’s an email I got back in 2012 about a team declining to participate in KPIs, turning down money. As far as I know, no one “lost their jobs."

Thanks very much for your message.
I did not blog about this, because my blog is still under construction.
We are a software company employing about 50 people.
A few years ago, our CEO introduced a company wide bonus system, based on 5 KPI’s. The KPI’s were different for every department, to be determined by the manager of the departments, like Direct Sales, Helpdesk, Development.
I told the CEO that, as a Scrum Master (and manager of the Development department), I could not decide on these KPI’s myself (nor did I want to), so I “took it to the team”, to coin a popular (and rightly so!) Agile phrase.
We discussed it in multiple sessions (I did not “lead” these sessions, nor did I put my view across, I just asked questions), but the team kept coming to the same conclusion: Any KPI we could come up with, either infringed on the Scrum principles, or deferred the team from the continuous improvement principle.
And believe me, we brainstormed about a lot of possibilities: Number of story points gotten credit for per sprint, number of iterations per story or task, newly reported bugs per sprint, even lines (and characters) of code.
Our bottom line was, that it just doesn’t sound right, quantifying performance on any other criteria than working software. And, adult and intelligent as we obviously are (I mean, we’re Development, right?), there will still always be this “hidden agenda” in the back of one’s mind, that makes one, for example, report two defects in one bug, or write a routine differently, to make it larger, in order to positively influence the KPI’s. It’s all unwanted distractions, in the end.
So ultimately, we unanimously decided to kindly refuse the offer. Much to the surprise of the rest of the company, including management. Priceless to see the look on their faces. Funnily enough, no-one asked us to explain why. I reported it to the CEO, and he understood. He’s into Agile. Thank God.
Up to this day, we still don’t participate in the bonus system.

I’ve used this example on a few occasions myself, because it’s very illustrative.
You’re absolutely welcome to share it with other people, if it contributes to spreading the word.

Kind regards
[name omitted pending permission to identify]
http://bit.ly/cl-feedforward <http://bit.ly/cl-feedforward>
Also, when I first started I was the manager (now I'm the agile coach), and I took the radical step of simply refusing to participate. We have a bonus plan that is based on company performance -- each department receives enough cash to pay out a percentage of everyone's salary and the head of that department can allocate it how they want. So I said pay everyone at 100% of their allocation.
There was a brief hot moment, but I shared with them how hard it is to pin down individual performance and what it does to team cohesion and they backed down. It also helped to build up a relationship with executives and a lot of transparency so they could see how much better the environment was than before I worked there, so they trusted my judgment.
http://www.strategy-business.com/article/00275?gko=c442b <http://www.strategy-business.com/article/00275?gko=c442b>
http://gojko.net/2008/08/07/paying-programmers-are-bonuses-bad-and-what-to-do-about-it <http://gojko.net/2008/08/07/paying-programmers-are-bonuses-bad-and-what-to-do-about-it>
Hope this helps!
Stephen Starkey
empathy | connectedness | restorative | relator | belief
http://coreagile.co/coaching <http://coreagile.co/coaching>
Sent from my iPad
shyamk77@yahoo.com [SCRUMDEVELOPMENT]
2015-05-22 11:44:58 UTC
Permalink
Hello Michael,

Here are links to links to some WSJ articles on the subject:


1) Get Rid of Performance Reviews: http://www.wsj.com/articles/SB122426318874844933 http://www.wsj.com/articles/SB122426318874844933


2) Yes, Everyone really does really hate performance reviews: http://www.wsj.com/articles/SB127093422486175363 http://www.wsj.com/articles/SB127093422486175363


3) Performance reviews lose steam: http://www.wsj.com/articles/SB10001424052970204319004577088810100916828 http://www.wsj.com/articles/SB10001424052970204319004577088810100916828


4) A Psychology Today article on "Why Performance Reveiws don't Improve Performance:" http://bit.ly/1IOWqkA http://bit.ly/1IOWqkA
5) Samuel Culbert - the UCLA Anderson School of Management Profession - turned his original WSJ article above into a book with the same title. Here is the link to the website of the book: www.performancepreview.com http://www.performancepreview.com/


Hope the above articles are sufficiently authoritative to help you with your objective.


It will be great if you could report back here here on how it all played out.



Good Luck in your quest !!!



With Best Regards


Shyam Kumar
Michael James mj4scrum@gmail.com [SCRUMDEVELOPMENT]
2015-05-22 14:06:30 UTC
Permalink
“In eight of the nine tasks we examined across the three experiments, higher incentives led to worse performance. In fact, we were surprised by the robustness of the effect;”
Dan Ariely, Uri Gneezy, George Loewenstein, and Nina Mazar (2005) “Large Stakes and Big Mistakes” Working Papers No. 5-011, Federal Reserve Bank of Boston

See also:
http://www.forbes.com/2009/02/19/bonuses-decrease-performance-leadership-compensation_dan_ariely.html
http://www.ted.com/talks/dan_pink_on_motivation.html
_Punished By Rewards_, Alfie Kohn, 1999
_Abolishing Performance Appraisals: Why They Backfire and What to Do Instead_, Coens/Jenkins (2000)

_Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management_ (Pfeffer/Sutton) (Chapter 5 addresses performance appraisals.)

Adobe's alternative to performance appraisals: http://www.hreonline.com/HRE/view/story.jhtml?id=534355695

I don’t know anyone who’s lost their jobs for refusing to participate in performance appraisals. I’ve refused to participate in them several years in a row, and still seemed to get the same raises everyone else got.

—mj
Post by ***@yahoo.com [SCRUMDEVELOPMENT]
Hello Michael,
1) Get Rid of Performance Reviews: http://www.wsj.com/articles/SB122426318874844933
2) Yes, Everyone really does really hate performance reviews: http://www.wsj.com/articles/SB127093422486175363
3) Performance reviews lose steam: http://www.wsj.com/articles/SB10001424052970204319004577088810100916828
4) A Psychology Today article on "Why Performance Reveiws don't Improve Performance:" http://bit.ly/1IOWqkA
5) Samuel Culbert - the UCLA Anderson School of Management Profession - turned his original WSJ article above into a book with the same title. Here is the link to the website of the book: www.performancepreview.com
Hope the above articles are sufficiently authoritative to help you with your objective.
It will be great if you could report back here here on how it all played out.
Good Luck in your quest !!!
With Best Regards
Shyam Kumar
Don Gray don@donaldegray.com [SCRUMDEVELOPMENT]
2015-05-22 15:28:37 UTC
Permalink
In addition to the books Michael listed, this popped up today as a beta read:

https://oikosofy.clickfunnels.com/get-rid-performance-appraisals <https://oikosofy.clickfunnels.com/get-rid-performance-appraisals>

Pierre Nels posted about it.

Sincerely,

Don Gray - Exploring Human Systems in Action
(336)414-4645

Join me for the next:
Coaching Beyond the Team <http://www.donaldegray.com/whatido/coaching-beyond-the-team-influencing-the-organization/>
May 11-12, 2015 Stockholm, Sweden

We do not rise to the level of our expectations.
We fall to the level of our training.
Author Unknown
Loading...