Performance Management Using Scrum

People Scrum

15 April 2014

Santhosh Vivekananda
Tata Consultancy Services


Scrum is widely used in the software industry today for the execution of projects. This paper uses the elements of Scrum and gives direction on extending the Scrum framework to conduct performance management. Only performance management is discussed in this paper, but the concept will be further extended to cover other aspects of people management as well.

Use of the Scrum framework in conducting performance management

The following practices in Scrum are very useful and provide lot of data in conducting efficient performance management.

As part of the daily stand-up meeting, each team member explains what they achieved since the last meeting and what they plan to achieve by the next meeting. This data can be verified against project and individual goals, and the data collated on a daily basis to evaluate performance.
  • Before the first sprint in a project, release plans are made and the team decides on roles. This opportunity can be used to set goals for each team member, matching their roles and the work planned in the project. This will ensure that the goals of an individual are mapped to that of the organization.
  • The sprint review meeting is conducted at the end of the sprint to review its output. Feedback is received from the project owner and other stakeholders, indicating the quality of the work done in the sprint. This data can be used to rate the work done by each team member in the sprint.
  • The sprint retrospective meeting is held to discuss what the team did right in the sprint, as well as what improvements may be required. Similarly, a brief meeting with team members can be planned to discuss each individual's performance against goals and what correction is needed to steer for better ratings.
  • The average of ratings for each individual's performance collected for each sprint will become the final rating of the employee at the end of appraisal cycle.
All techniques that are part of the Scrum framework can be used to implement an effective and transparent performance appraisal process. This also enables employees to receive on-time feedback and make corrections, at the same time averaging the rating. The following paragraphs explain the various roles, events, artifacts, and rules binding all of them to enable implementation of such a process.

Problems in the current performance appraisal processes

The generally followed performance appraisal process leads to following problems:

From the appraisee's point of view
  • My good work done in the initial phase of the appraisal cycle has not been considered properly during appraisal discussion (it has been forgotten!).
  • I do not get regular feedback about my work. The majority of comments are during the appraisal discussion, and hence I did not get a chance to improve my rating beforehand.
  • The goals assigned to me at the start of the appraisal cycle are not aligned to the work I am doing in this project, nor to the role I am playing.
  • When my goals were set, I was part of another project and had another role. Though feedback from the previous manager was received, my current feedback doesn't reflect the quality of work I did there since my new manager is not happy with the work I am doing here in a new role.
  • I do not know how my rating has been arrived at. I do not have transparency on the whole process.
  • I am not part of a project now but was part of a project in this appraisal cycle initially, and I did a very good job. I'm not sure how that work will be considered.
From the appraiser's point of view
  • I have many employees reporting to me, and it is difficult to complete an efficient appraisal at the end of the appraisal cycle for so many people.
  • Having a fruitful discussion about the entire period of the appraisal cycle with each appraisee is difficult.
  • Generally, the majority of my employees are not happy with their rating and feel they deserved a better one.
  • Goals set by the previous manager may not be appropriate for the role an employee is currently playing in my project.
  • There is difficulty in comparing the performances of different roles to fit a curve.
From the organization's point of view
  • There is not much transparency in the process. We cannot guarantee that favoritism does not come into picture.
  • The current process tracks goals and key performance indicators that were defined at the start of the appraisal cycle. These have not been revised or updated as the organization's goals changed or projects changed.
  • It's difficult to compare for curve fitting, even for similar roles across projects.
  • We cannot motivate employees and increase the accountability in the current process.
  • There may be timeboxes during the appraisal cycle in which an employee was not used properly, either because of role mismatch or not having enough work. Actual bench strength is more if the time employees are idle is considered.
  • Employee productivity is not constantly monitored, costing money to the company.
  • It is always useful if an organization can understand any misfit of roles early, rather than at the end of the appraisal cycle.
  • Work completed should be considered more strongly for the performance appraisal than any future dependency on the employee in any project.
The items listed above and many more such issues will be addressed in the approach discussed below.

People Scrum: A concept

The goal of the "People Scrum" approach is as follows:
  • Use the Scrum framework for efficient and transparent performance appraisals.
  • Use pillars of Scrum leading to an empirical process: transparency, inspection, and adaptation.
  • Enable employees to get early feedback on:
    • Performance
    • Fit for role
  • Enable a transparent and efficient process leading to best performance and best use
The process can be implemented in projects using Scrum and slowly expanded to the entire company.

Roles
Following are the roles in People Scrum:
  • Appraisee: All members of the Scrum team are appraisees. Each team member's performance is measured, and hence they all assume the role of appraisee. An appraisee is responsible for clearly and concisely presenting the work completed and work planned in the sprint meeting. The appraisee also highlights any blocking issues in completing the work planned and assigned. These parameters are used by the appraiser to assess the performance in every sprint. Therefore it is important for the appraisee to take responsibility for highlighting the work done one day at a time in his or her Appraisee Daily Performance chart. This chart is used to capture self-appraisal on a daily basis.
  • Appraiser: This role can be handled by the ScrumMaster. If it is handled by a project manager who is not part of the Scrum team, input should be taken from the ScrumMaster. The appraiser will use the sprint meeting data and start converting it to daily ratings for each appraisee. The appraiser cannot have less than five or more than nine appraisees. This is in line with the Scrum development team size. The limited number of appraisees helps in conducting an efficient and transparent appraisal. The appraiser is responsible for conducting a "People Sprint Review" meeting with each of appraisee at the end of each sprint. The artifact in which ratings are captured, along with comments, is known as the Appraiser Daily Performance chart.
  • Reviewer: A senior manager in the organization can play this role. It is similar to the current role of a reviewer: the reviewer is responsible for addressing any conflict arising in the People Sprint review.

Artifacts
Following are the artifacts produced during the appraisal cycle as part of People Scrum. They hold data updated by the different roles.
  • Goals list: The list of goals is set at the start of each project by the appraiser for each appraisee. The list of goals is organization specific, but the goals are derived based on the role the appraisee in playing in the current project, as well as considering organizational goals. The goal list can get refined after every sprint. The discussion about goal-list refinement happens in the People Sprint Retrospective meeting.
  • Appraisee Daily Performance Chart: Maintained by each appraisee, it contains a self-appraisal rating for each working day of a sprint. The chart also contains comments validating the rating and specifying the alignment of work done with goals set the appraiser.
  • Appraiser Daily Performance Chart: Maintained by the appraiser, it contains an appraisal rating for each working day of a sprint. This can be updated by the appraiser on a daily basis. One chart is maintained for each appraisee. It is important for the appraiser not to invest too much time in updating the sheet every day. A maximum of 5 minutes should be allotted every day for each chart. The appraiser is also free to update the chart on a weekly basis, but it is advisable to do it daily. The chart is used along with the Appraisee Daily Performance Chart for a discussion at the end of each sprint in the People Sprint review meeting.
Events
  • Goal-setting meeting: This meeting is held at the start of a project. Its intention is to set goals that are aligned to the project goals and also to the organizational goals. The goals set to each appraisee should also be in line with his or her role in the project. The appraiser will have a meeting with each appraisee. This is a one-time activity for the entire project. The meeting is timeboxed for 30 minutes. The appraiser should come to the meeting with defined goals. The goals can be tweaked in this meeting after discussion with the appraisee. Organizations can follow their own goals list for different roles, but the format has to be standardized across the organization.
  • Updating the Appraisee Daily Performance Chart: The appraisee should update the daily performance chart regularly, preferably every working day. This is a timeboxed event of 5 minutes. It is better done after the sprint meeting to capture the essence of work done discussed in that meeting, along with due consideration of goals set against each role. Organizations can follow their own format, but the format has to be standardized across the organization.
  • Updating the Appraiser Daily Performance Chart: The appraiser updates one such chart for each appraisee. Though the appraiser is free to do it once in a week, it is suggested that it be done every working day. This is also a timeboxed event of 5 minutes.
  • People Sprint review meeting: This meeting is held once at the end of every sprint. It is a timeboxed event of a maximum of 30 minutes for a 4-week sprint for each appraisee. This meeting is held for each appraisee separately. In this meeting, the appraiser will go through the Daily Performance Chart maintained for the appraisee, along with the self-appraisal chart filled in by the appraisee. Importance is given to the alignment of tasks against goals. Importance should also be given to the quality and timeliness of task completion. At the end of this meeting, a rating of the appraisee for the just-completed sprint is finalized. If there is any disagreement about the final rating or the comments, a follow-up meeting with the reviewer can be held. The finalized rating for the appraisee is communicated to the appraisee and the reviewer in a formal way.
  • Goal retrospective meeting: If, during the People Sprint review meeting, the appraiser and appraisee both realize a need to update goals, a goal retrospective meeting will be held. Following are some examples:
    • Goals not matching to the role being played by the appraisee
    • Unachievable goals
    • Goal targets being met very easily
    This meeting is necessary to validate the goals. The output of this meeting would be an updated goal sheet for an appraisee, agreed upon by both appraiser and appraisee. The reviewer can, optionally, be invited to this meeting, depending on the requirement. This meeting is a timeboxed event of 30 minutes.

Further information
The end-of-the-year rating is an average of all sprint ratings. There is no need for discussion, since every discussion was held at the end of each sprint.

Holidays/leaves (not weekends) will average in to the rating the employee receives. This is to encourage people to take leaves (encouraging work-life balance).


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 1.5 (19 ratings)

Comments

Zach Bonaker, CSP,CSM,CSPO, 4/15/2014 9:42:46 AM
I get the impression that the need for "performance management", as it pertains to Scrum, may have cultural implications that I am not aware of. Therefore, I'm hesitant to comment for fear of ignorance.

However, I'll simply say that topics like "sprint ratings" and "measuring individual performance in a sprint" make me highly uncomfortable from a manifesto standpoint.
Santhosh Vivekananda, CSM, 4/15/2014 12:58:59 PM
Hi, Thanks for your comment. On the contrary, it is to give more transparency and checks and measures which eventually helps the team which has the ability in Scrum to decide on the work they want to do
Jem Djelal, CSM,CSPO, 4/15/2014 2:18:15 PM
Why do you need to manage performance? If you want to know if your team are performing, then look at two things - the working software they have created & their morale in the work place. Also. We in Scrum want self managing teams, tell me how your article supports the emergence of self management?

To add, transparency for the purpose of micromanagement is not healthy. Transparency for the sake of transparency of not only harmful to the team, the individuals but is also a waste of any leaders (note not 'managers' energy).

I second Zach's comments on individual measurement. This is a very bad idea - Scrum focuses on Team goals, not individual goals. What happens when you have identified that the 'individual velocity' of Paul is 10 and he is your 'highest performer' - will Paul want to help James who is junior to the team in a task he is struggling when he knows that he is the 'highest performer' and he has been incentivised to focus on his individual goal? Now Junior James didn't get help for that task and is struggling with the TDD side of things and instead wings it, negotiates code quality and now we're working against the goal of high quality which Scrum is very much focused about.

Measure teams, not individuals.
Deepak Srinivasan, CSP,CSM, 4/15/2014 3:09:31 PM
Performance management ties into the same goals that scrum or agile or any other methodology seeks to solve for the engineering process.

Taken in that context, Zach's and Jem's comments make total sense. Scrum is silent on performance management. A good manager practices an art - the art is one of individualizing a person and balancing the team.
Zach Bonaker, CSP,CSM,CSPO, 4/15/2014 4:26:19 PM
@Deepak: I'll expand the scope of your statement and suggest that Agile, as a whole, is silent on performance management.

Thus my concern when contextually applied with Scrum. Individual assessment is a philosophical topic for the larger organization. I don't understand the justification to impose commonalities.
Santhosh Vivekananda, CSM, 4/15/2014 8:51:25 PM
Thank you all for your comments. Please look at the way performance management is done currently in most of the organizations. Goals can be set which promotes helping other team members!. The concept of using Scrum to improve the way we develop software can surely be used in improving the way performance management is done. Not only transparency but constant inputs to see how performance can be improved can help team a lot. Also note the situations when an employee moves from one project to another within a appraisal cycle. This helps in getting clear feedback into the system from first project.

This is just an idea which surely can be fine tuned with all your inputs
Santhosh Vivekananda, CSM, 4/15/2014 9:27:49 PM
On another note, how do we implement Scrum successfully? Involve other roles in the organization. How do we get HR to support implementation of Scrum? If they can see the data Scrum can provide to do their job better, there will be more acceptances. Most of the Scrum failures are due to not implementing Scrum properly. Expand the Scrum framework to support other functionalities in an organization and it will surely help strengthen Scrum practices and its implementation
Albert Arul Prakash Rajendran, CSM,CSPO, 4/16/2014 3:18:12 AM
Santhosh though there are couple of points which are good (like scrum master input should be considered etc), I get a feel that, the scrum master becomes a manager over the period of time who over looks (better term than micromanage) how an individual member is working on a particular task and give a rating towards that.

Now this overlooking concept actually demotes people to pull their work by themselves and most complex (algorithms, optimization etc) work will not be pulled voluntarily. Also this rating individuals will bring finger pointing game (when things go bad) and there will not be a place for better communication and collaboration

Here again the topic of rating an individual (in a scale) is completely philosophical where we say, you meet expectation if you get rating 3. anyone below rating 3 needs corrective measures.

In scrum we don't deal with too much of data points and definitely not individual data points.

Just for a discussion sake, what would be your rating for an individual who did not complete his work for past 3 days (estimate is 1 day). Does this not add pressure on that individual like our waterfall manager do.

Here again we are trying to bind a team member to the estimate that is provided by them. In agile the estimate was provided as a team not by an individual. Also an estimate is JUST an estimate, which is never accurate.

Even if we need to look at the goal set for every sprint for individual, Can you explain us what type of goal setting for an architect role (by title), a software engineer (by title) or a QA engineer. This requires scrum master to be technically sound before setting the goal. Another interesting thing is how are we going to align this with our sprint Goal. Also, this blocks team members to be collabrative in development and box themselves within their goal.

Why does HR functional need to support Agile implementation of the organization. Agile implementation is a framework for developing software. HR has no say on that. This is my humble thought.
Albert Arul Prakash Rajendran, CSM,CSPO, 4/16/2014 3:25:15 AM
I like to link to a Harvard Business review article on The Relationship Between Anxiety and Performance

http://blogs.hbr.org/2014/01/the-relationship-between-anxiety-and-performance/

This article deals with how performance is affected with anxiety.
Deepak Srinivasan, CSP,CSM, 4/16/2014 7:53:42 AM
@Santosh - "Expand the Scrum framework to support other functionalities in an organization and it will surely help strengthen Scrum practices and its implementation"
Agreed! but disagree with the use of the word "expand". instead ask other areas of the organization to grasp the essence of scrum. not very hard. then ask them to devise methods by which the organizations culture as well as scrum goals are not subverted in coordination with the team. ask the team how they would like the bonus pool or money allocated to increases be allocated.
Santhosh Vivekananda, CSM, 4/16/2014 10:08:56 PM
Thanks Deepak and Albert for your comments.
Albert, performance appraisal is a part of work culture which we cannot avoid. Today it is done in a manner which is not transparent. I see lot of issues in the current way it is done and Scrum practices can really help in making it better. I am more thinking from team point of view here. Actually, it will help team members . If somebody is evaluating performance half yearly or yearly, why not do it in a better way? As in Scrum, it is just a framework adapted to organizations.
Tim Baffa, CSM, 4/17/2014 12:09:35 PM
Santhosh, some observations from your posts that do not seem to conform to a scrum structure of performance management:

1) Having the scrum master provide the ratings for individual team performance effectively gives them a level of authority over the team, which is a huge no-no in Scrum. The scrum master serves the team in a completely non-authoritarian role.

2) While it is true that many organizations have issues with how individuals are reviewed, attempting to "morph" scrum to solve this appears to be a poor choice. Scrum should NEVER be used to identify or recognize individual performance. A major goal of Scrum is to grow the team and have the team as a whole accept responsibility for their work. There simply is no "I" in team, especially in agile.

3) The 360-review type performance appraisal within a team is something that I have seen, both inside and outside of Scrum, and it can be effective. Usually however, a team is very aware of how they are performing, who the "weak" links are, and the scrum master can work with these team concerns to help strengthen the team as a whole.

4) Applying an inspect and adapt model to performance management is actually very desirable. This is one agile practice that can be used to improve the appraisal process. What I have seen work very well in some organizations is the evaluation of the individual not only by "team" performance and the "team" goals achieved, but also by the growth of the individual in their learning and proficiency over the review period. Has the individual become a stronger resource to the organization or not? This is the critical question that may be missing from many performance review processes.
Ron Jeffries, CST,CSP,CSM,CSD,CSPO,REP, 5/29/2014 7:08:00 PM
I've not seen this in action. From a distance, it is just about as far from consistent with Agile and Scrum values as anything I've seen.

For reasoned discussion of why this may well be bad, see "Punished by Rewards" by Alfie Kohn. For a better approach to getting productivity -- not measuring it -- see "Drive" by Daniel Pink.
David Lowe, CSP,CSM, 5/30/2014 5:16:26 AM
Wow.

Good luck recruiting anyone to come and work in a team with that in place. Would definitely suggest you buy a copy of Pink's Drive.
Luis Goncalves, CSM,CSPO, 5/30/2014 6:57:24 AM
Dear Santhosh,

I must say that is quite sad to see what you wrote...

Basically it shows that you really do not have a great understanding about how organisations should be managed.

I could go into many details but if you are interested in learning more about the topic check this out: lmsgoncalves.com/performance-appraisals/

Cheers
Luis
Steven Mak, CSP,CSM,CSPO,REP, 5/30/2014 10:06:14 AM
In addition, I wish this article has never been published, especially under scrumalliance.org
Mark Levison, CST,CSP,CSM,CSPO,REP, 5/30/2014 10:34:13 AM
Santhosh - this antithetcial to everything Scrum represents. Scrum is about humanizing work and maximizing the performance of teams. You create high performing teams by helping the people build working relationships not by measuring the performance of individuals.

This goes not only against the spirit of Scrum and Agile, but also against what modern beahvaioural psychology tells us.
Michael James, CST,CSP,CSM,REP, 5/30/2014 11:25:26 AM
I'm surprised this article was published, as it contradicts Scrum, Agile, and everything else we've learned since the last century. For an alternative viewpoint, see "What HR Doesn't Know About Scrum" http://scrumreferencecard.com/WhatHRDoesntKnowAboutScrum_BetterSoftwareMagazine.pdf
Steven Crago, CSP,CSM, 5/30/2014 12:21:08 PM
I'm actually surprised this made it past the review process. It is so antithetical to agile and scrum.
Scrum Alliance, 5/30/2014 2:49:53 PM
Thanks to those of you who are entering this conversation in the spirit of a learning community, remembering Scrum’s core values of Commitment, Focus, Openness, Respect, and Courage.

We all struggle with the practical realities of implementing Scrum in our individual work places, and those realities do not always jibe immediately with the ideal. Scrum is indeed a journey. In this forum of member-submitted articles, writers turn to the community for a give-and-take of ideas, advice, experience, and learning. In follow-up comments, we appreciate supportive feedback that leads to better understanding and implementation of Scrum.
Bob Hartman, CST,CSC,CSP,CSM,CSPO,REP, 5/30/2014 6:25:50 PM
Santhosh, your belief in the statement you made to Albert: "performance appraisal is a part of work culture which we cannot avoid" is at the root of the issue here. There are many, many ways in which performance appraisals and their associated problems can be avoided. Companies choose not to do those things for various reasons.

Several resources have already been suggested, including "Drive" by Daniel Pink. There are many, many others available which help companies understand the horrible effects of their current cultures. I would prefer we help people understand how to change their culture than how to keep the culture present when using Scrum.

If you made the big leap of thought to say that performance appraisals should be avoided because they result in bad things happening, how would that change your thinking about your article?
Henri Laine, CSM,CSPO, 6/2/2014 7:50:45 AM
Santhosh, Remember that at the heart of scrumm is the "self organizing team" The team engages to the sprint together, and achieves or fails together. There is very little room in this for individual performance appraisals, that would go fundamentally against the ideals of Scrumm.

Secondly, Scrum master should never ever engage into performance appraisals of individual team members. The SM is leader sans authority and a trustee whose work, remember, is getting rid of the impediments before the team and facilitating the teams efforts to get to the goals.

If you find yourself in situation where the performance of a team member is questioned, the correct response is not to engage into appraisals, but to find out why that guy is failing and if the rest of the team needs to do something to raise his performance level somehow.
Mika Turunen, CSM, 6/5/2014 4:03:47 AM
Santhosh, Honestly, I think this is the exact opposite of what Scrum is. The team should be allowed to self organize and no individual should be brought up from the team but instead handle them as a team and allow them to swarm pn the tasks they've committed to.

I fear that using this kind of methodology absolutely smashes the advantages of Scrum. I could be wrong and I'm looking forward to hearing more of this.
Deepak Rawat, CSM, 6/17/2014 3:35:16 PM
Santhosh, Scrum prescribes team work. Teams are encouraged to self-organize to increase productivity. Scrum teaches us that whole scrum team is accountable for product increments, so we rate the team as a whole.

But dont get disheartened just with this article, I would encourage you to write more articles maybe in accordance with the spirit of Scrum next time.

You must Login or Signup to comment.