Monday, September 5, 2011

Doing year end appraisals in SCRUM projects

This is a wonderful discussion, I'm sure it'll be very helpful in the industry often. Just want to preserve it.

Begin forwarded message:
From: Madhur Kathuria <
Date: 5 September 2011 11:18:38 GMT+08:00

Though there can be essays written about how an appraisal method is better or worse than the other one, it is important that there is a pragmatic approach taken to identify the facets of the appraisal process which answer concerns from all functions

By simply saying that non-engineering functions do not understand Scrum seems to me like running away from the responsibility of taking everybody along on the same journey path to Agile benefits

So, I would recommend the coaches to take inputs from the previous data and some of the experiences provided in similar forums like this and decide what works for them by involving everyone in the process mapping exercise.

On 3 September 2011 17:17, ashu tosh < wrote:


Year End appraisals in software industry are considered to be medium for final Ratings which impacts your compensation & promotions.

Now as SCRUM is team work and team decides for tasks to be given to whom so I am not sure considering contributions will help people in accepting the ratings

On top of it, now a days HR has started introducing Quaterly appraisals which can have negative impact on team members because on one side we are talking about removing obstacles and delivering more and on another side we are discussing the output as part of appraislas.

Since there are organizations who adopted SCRUM at a large level like salesforce or yahoo so it can be good if we can try to get some inputs from these organizations.

May be we can decide this as the topic for next scrum meet in Delhi region.

--- In, Vikrama Dhiman <vickydhiman@... wrote:
Madhur wrote:
Typically, 60-70% of the rating of a team members should be governed by the teamfulfillingtheir team goals every sprint.
I am not sure about that one. If compliance with team goals is what is being measured, teams will never set a stretch goal and you are also likely discouraging failure and risk. In the best case, this sorts of rewards right estimation, which again is something debatable. If a team set a goal at 100 and achieved 80, and another set a goal at 60 and achieved 65 - who did better [assuming all goals are standardized - which again is highly unlikely.]
The number 1 challenge in an appraisal process is what data to collect and second is how to assess people on it. Data I have recommended is [collected and appraised quarterly]:
See how the team thinks it did in a quarter
See how PO thinks it did in that quarter
See how team thinks each team member did it in a quarter - on parameters like learning, performance, contribution
See how the manager thinks each team member did in a quarter OR The Scrum Master provides information to HR about that [note the SM is not judging the performance, just providing the information]
See how the individual member thinks he did in a quarterSee the obstacle list at the start of the quarter and end - and find out if there are major obstacles that are stopping team across the board from achieving potentialHave the team present a report on what they have achieved in the quarter to an appraisal panel - comprising of random members from across the organization

Make sure you have clear numbers and data. You can keep a track of qualitative data too - for instance, if you want to reward going beyond the call of duty or collaboration, managers need to record that data regularly.
Now, with all this data, you can see what appraisal/ increments should be given. Share the criteria and formulas used publicly and debate them before adoption.
Also, here is what you should do as a Priority Number 1
Make sure HR/ Accounts/ Management understands Scrum. Organize a workshop for them and involve them as part of the change.
Most often these functions don't understand Scrum and that's where disconnect happens.
I have never seen a "fair" and "objective" appraisal process interfere with Scrum. What hampers Scrum is different perceptions on "fairness" of appraisal process. Address that and you'll be good.
Happy to answer any further questions!
--- On Fri, 9/2/11, Tarun Sharma <superchamp1232002@... wrote:
From: Tarun Sharma <superchamp1232002@...


I completely agree with Madhur and just to add below can also be helpful for appraisal -

1. Sprint Backlog can be used to know individual velocity over a period of time to understand invidiual contribution to the team.
2. Rotating coordinator roles such as Standup coordinator, user story and QA coordinator, show and tell cooridnator, testing coordinatoretc helps to understand
and review the way individuals take initiatives in the team

From: Amit Mehra (Bgh) <amit.mehra@...
Sent: Friday, 2 September 2011, 6:42
I read Madhur's reply after sending my email. Just want to add that I agree with what Madhur has stated. These are the line of thoughts on which teams need to experiment.

Amit Mehra

Sent: Thursday, September 01, 2011 9:25 PM
Hi Ashutosh,
Team factor is a major area in appraisals for the agile team.
Typically, 60-70% of the rating of a team members should be governed by the teamfulfillingtheir team goals every sprint.
about 10-20%weight-ageis given to an individual members through the ratings received from other team members. This can be done through a 360 degree feedback survey
Rest of theweight-ageis given to the team member fulfilling his/her learning and growth targets for the appraisal year.
As part of the appraisal, it is essential that the manager is part of the team review and planning meetings (more as a silent chicken) and get the smells and the undercurrents from the teambehavior.

As i have been stating in my earlier posts, by no means is the above suggested combination the final word towards a good agile team appraisal. This can more be a guide rail with the final division being decided based on the team environment and management considerations
With Regards,
Madhur Kathuria, CSC, CSP, CSM, CSA
On 1 September 2011 15:59, Riju Kansal <riju.kansal@... wrote:

This is the most difficult part of the year.
My 2 cents: Ideally there shouldnt be any competition within a scrum team. It was a team effort and each team member helped achieve successful done state for each story. So if the team's work got appreciated and was visible clearly to the management they all should get appropriate equal ratings. This may differ in case there were clear attitude issues with a team member.
-Riju VK
On 1 Sep 2011, at 13:50, "ashu tosh" <goyalashutosh11@... wrote:
Recently I have switched to SCRUM methodology in executing the projects. MY CSM training and this blog is helping me alot.
I wanted to know how appraisals should be done differently in SCRUM based projects because during sprints we never focused on the couting defects leaked by individual team members. At that point of time, focus was to identify improvement areas and deliver better.

Sunday, September 4, 2011

Day 1 at scrum team

We have just got started with our scrum team today.

We are a team of six plus PO, SM and BA. We had our daily standup meeting with updates from "The Team" including Dev and QA guys. We also had SCRUM Master, Delivery Manager, QA Manager and BA present during our stand up but they did not give any updates.

Our new scrum master gave us a quick overview of how we are going to proceed, little bit about the meetings and how the backlog will be filled. We plan to have a quick planning meeting in the afternoon where we are going to discuss the ongoing tasks. So now a little background, we are an existing team with developers and testers taking on delivery items from two to three lines of business. The businesses directly contact testers and devs to giv and teak the detail and get started with the work. The QA team has to give signoff for the changes and it is considered as go ahead for a release.

So we are basically in our sprint zero the delivery manager and scrum master have taken this task of roling out SCRUM for the team and they are trying hard for it.

Lots of Good Luck to the new SCRUM Team.

Please access the attached hyperlink for an important electronic communications disclaimer:

Saturday, September 3, 2011

The indispensable traits of a Scrum Master

The indispensable traits of a Scrum Master are:
- emotional stability
- consistency
- diplomacy
- empathy
- good communication
- intuition
- good negotiator
- courage

These are all "soft" skills, so technical knowledge is irrelevant.

But if the SM determines that she wants to lead the team into adopting technical practices (unit testing, acceptance testing, simple design, refactoring, TDD etc.), some level of technical knowledge is beneficial to "getting the word across", and even providing initial training.