Thursday, April 01, 2010

Agile Appraisals


Performance Appraisals have become the irreplaceable parts of organizational operational processes and very much for a reason. Come April and all discussion topics on operation floor reduce to just Appraisal. Everyone tends to forget how badly did they perform throughout the year and all of a sudden there is a heavy crop of all the good work that each of us have done. Everyone believes s/he is the start performer of the year irrespective of all the screw ups during the year. Loads of Appraisal forms are printed and hours of time is invested in filling the applications. In all this, one important point that everyone tends to overlook is that Appraisal Ratings are not assigned overnight by the reporting manager, but are accumulated over the period based on your own performance. However if you are thinking the accumulation period is last one year or so, then you are wrong. As a matter of fact, appraisals are based on your performance for last 3-4 months only. Pull any of your own appraisals to date and check it against your performance. I bet my breath on it that you would just not find any match between your rating and your performance at the beginning of the year. As a matter of fact, some excellent accomplishment at the beginning of the year must have been considered to be an obvious thing … you know call of the duty or that is what is expected from your role anyways. But you turn a bad situation into good one or vice a versa in just last 3-4 months and you would find yourself in a sweet spot.

This has worked for organizations for long time. However there are critical issues with the process. One we just talked about, but the most critical one being the traditional appraisals are very influence driven. Most of these appraisals do not talk about your performance, but of what your reporting manager thinks about you. The ratings are a matter of Bargain – you think you need 8, I think you deserve 5, so let us settle for a 6 or a 7. Come on, if you as a reporting manager believe I deserve a 5 then why not stick to your guns? Or are you not so sure about it? The process is not very transparent and also is influenced by the sense of superiority – if you know what I mean. Another big issue is that the traditional method is based on the objectives or Key Result Areas, that are defined at the beginning of the year. But how many times are these KRAs or objectives practical and that to for the entire duration of year. You think the KRAs will be static for the rest of the year ….. Give me a break.

Agility looks at the appraisal process a little differently. We all know that Agility is about team work, about ownership and about empowerment. So it puts the appraisal process in employees' hands. With Agile, the boundaries of roles of Resource and Reporting Manager get erased, and as a result the traditional appraisal system finds itself in nowhere-land.

Agile proposes a flat team structure without any reporting authorities and with equal responsibilities. Project success or failure is a team effort and individual performances become a part of history. And therefore it becomes very much important, for all the HR representatives at least, to brain storm on a new way of appraising the Agile Teams. Couple of options I could think of are:

1. Celebrate and/or punish entire Team’s (non)Performance. Treat and rate every individual the uniform way. So each of us gets the same raise or no one gets it. The challenge here is – no matter how much we read that it is all about team performance, it is rare that a team is successful without individual heroes. And we risk of frustrating these individual performers by putting them at the same table as that of low performers. (Another school of thought here is if an individual thinks s/he is smarter than rest of the team, s/he is not fit to be on an Agile team anyways).

2. Another better way is to have Scrum Master do the appraisals in discussion with entire team. This may work where a Project Manager is pretending to be the Scrum Master. But Scrum Master by definition is not in position for this job.

3. The third and the best way, at least according to me, is to let the teams conduct appraisals internally for everyone. The way it should be done is:
  • Each team members appraises every other member on three aspects (there is no need to weight any of these aspects separately as all of them are equally important)
    • Technical
    • Soft Skills
    • Team Player
    • Alignment towards Organizational values / growth
  • Average the ratings given by rest of the team to get individual’s rating (and be sure to adjust the outliers by discussion)
  • Apply the Project Success Factor (PSF) to individual’s rating to flatten it at organizational level. PSF could be as simple as the impression of Senior Management or as complex as special derivative of various factors including Project Profitability, Schedule Variance, Resource Maturity Index, Customer Satisfaction Index, etc. The PSF would be equally applicable to each of the team members.
  • The key is to gather multiple data points. So just like frequent sprints, gather the data points every quarter (or at the end of the project if project is of small duration).

My point of view, option 3 this is the most agile way appraising individuals and teams – irrespective of the project methodology. It will ensure the individuals are rated properly, will maintain the organizational harmony during and after the process and most importantly will enforce the team spirit and team work in individuals. After all, you just don’t have to behave with your Reporting Manager, but also respect your team members.

Let me know if you have a better way than this. Did I hear “Scrap the appraisals”?

4 comments:

Anonymous said...

Oh no way i will scrap the appraisal process..

I find this posting very unpractical and irrlevant. Agile is for project delivery , why are we taking to this level which has no relation at all.

Point 1 :- Celebrate and/or punish entire Team’s (non)Performance
Out of question this will work. Some stupid team member does not work and the whole team should be punished. In traditional methodology only non-performance are punishes , so what the big diff does it make with this sentence.

Point 2 :- Another better way is to have Scrum Master do the appraisals in discussion with entire team

So like tradition approach we have just replaced the project manager with the scrum master. Give me a break thats already happening.

Point 3 :- The third and the best way, at least according to me, is to let the teams conduct appraisals internally for everyone.

Hmmm is n't that something called 360 degree.

360 degree works for assesmentas there is a cross feedback. Lets not make Agile for everything and the only thing in the world for all problems.

mad-z said...

Dear Anonymous
I feel you probably did not understand the Agile concept altogether. Agile is not just about Project Delivery. Rather if you look at Agility, it is about how the organizations should operate and that covers everything from Operations to HR to Training to IT to Admin ... everything you can think of.

I can possibly go an explain each option in detail, but that will turn out to be a separate blog post. So let me give a try in brief here.

Everything you do in Agile is required to be looked at as the Team Effort. The core success factor of Agility is the thought "we are all in it together". So my option 1 comes from there.

The second option is not about replacing the PM with a Scrum Master. From the outskirts it may look like that, but read between the lines and I clearly say "in discussion with team". So here the SM is actually extending Option 1 and facilitating the discussion and rating process.

Regarding option 3, 360 is part of it. 360 is also termed as Reverse Appraisal (RA). You too mention about 360 being a Cross Feedback (CF). But the term RA or CF emphasizes the team hierarchy and hierarchical structure has no place in Agile. So calling it RA or misunderstanding with 360 would be a disaster.

I possibly can go distance explaining this. or we may have an intelligent discussion over the topic. Need to figure out a way how we can do this though. Share your IM (google, skype, or anything else) and we will connect.

And as far as Scraping the Appraisal Process is concerned, I would support the movement if we can come up with a better way of analyzing team success and rewarding them.

Anonymous said...

Something we should discuss as anonymous.

Your Quote :- it is about how the organizations should operate

My Answer :- If you look at the principles of Agile Satisy customer by,delivering valuable software,Welcome change,Working software,Motivate individuals etc etc. Any of these principles do they match with assesment logic ?. My main problem with the above posting is you are trying to relate to something which Agile is not directly applicable. Its a small linkage which you are trying to amplify which has no meaning at all.

Your Quote :- Everything you do in Agile is required to be looked at as the Team Effort

My answer :- Agreed its a team effort. Now is that the strong reason for a good assesment system. Assesment system is not a team effort , its about rating someone how good or bad it is. Its not a project. The time people have monetary benefits they will not work as team. Working with customer is a different aspect.

Your quote :- So here the SM is actually extending Option 1 and facilitating the discussion and rating process.

My answer :- Looks like you agree with me. My only thought here is some one has just replaced some one. Like the king getting replaced by the PM. Now do not say PM is superior to King , its just a example.

Your Quote :- I feel you probably did not understand the Agile concept altogether.

My answer :- I am not born BOND in this topic. But what i understand is

Does "satisfy the customer" match with "ASSESMENT" then i am a pope.
Does "Welcome changing requirements" match with "ASSESMENT" then i am a pope.
Does "Deliver working software frequently" match with "ASSESMENT" then i am a pope.
Does "motivated individuals" match with "ASSESMENT" then i am a pope.
Does "face-to-face conversation" match with "ASSESMENT" then i am a pope.
Does "Simplicity" match with "ASSESMENT" then i am a pope.
Does "Incremental releases and iteration" match with "ASSESMENT" then i am a pope.

You have made two sentences which are connected in a very very mild format "Milk is good for health" and "Milk is a cure for cancer". The "MILK" has relation with health but we can generalize it as full cure for everything.

We can agree to disagree , i think we do to a great extent.

I prefer talking through your blog , if you are fine.

mad-z said...

Dear Anonymous Friend,

Thanks for responding because this will keep the communication live. Though disagree, what matters is the communication. In the end, I am sure we will agree on the points.

From what you wrote, couple of initial points.
1. It seems you are confused between Agile and Scrum. All your points are talking about Scrum where as my blog post is about Agile.

Agile is the philosophy that is based on values and principles where as Scrum is the methodology under the Agile Umbrella. Like Scrum there are many other methodologies which focus on various values and principles of Agile.

I will also propose you read my earlier post titled "Agility as Behavior" at http://dineshmadne.blogspot.com/2010/01/agility-as-behavior.html. Also go over this link: http://scrummethodology.com/

I am not sure if I need to answer pointwise on your comment at the moment. Just to touch couple of items from your post -

You ask - "Is team effort a strong reason for a good assesment system".
If you read on the topic further, you would find that Agile community does not call for assessment of individuals. Assessment by nature will create a spat between teams. And hence the community feels there should be a new way to either reward or assess the team.

You say "Looks like you agree with me. My only thought here is some one has just replaced some one."
When you compare two methodologies for same purpose, then be it software development or any other trade, you would always have a replacement. But if you look at it as a role only, then there is a problem. Look at it as a responsibility and what is expected from that role. A driver is a driver, but you call it a pilot when she is flying the plane. Now that does not mean they are same and JUST replacing each other.

I donot want to comment about your being bond in Agile or not. But my suggestion would be do not throw the thought right out. Think about it and see if you can digest. Agile calls for experimentation, and no experiment would be successful without at least a trial. I am working on Agile for more than 5 years now, and appreciate it heavily.

Anyways, I would look forward to hear from you when you do a little more reading on Agile. Especially see how Agile and Scrum are different. And then we can talk.