Performance Management for Agile People


Managers are required to determine who is performing better so they can be rewarded more than others who are judged to be doing not as well. Also, managers are required to do performance appraisals because that is what everybody at the company is required to do.

It's a tricky place to be, but there are some compromises and approaches that have been shown to work for many managers in this situation.

Team Goals

While most systems focus on the individual, most agile people feel that the team should be judged and rewarded if anybody is going to be judged and rewarded. Managers are used to sitting down at the beginning of the year and establishing some kind of performance goals for each employee. So, here's a tip that is perfectly workable: Give all of the members of an agile team the same performance goals. When you do this, several things happen. First is that you find that you have to establish goals that are higher level than the individual goals that you are used to. "Complete the design of the file system thingie and implement it" is a common form of individual performance goal for software developers. But, if you are going to give goals to a team, they need to be in the form "Ship Frboz Release 1.0 in Q2." That's something a team does. By giving each member of a team the same goal, you have just implemented a team goal.

The second thing that happens is that people feel more comfortable contributing to the team goals since they are also each individual's goals. At review time, the review discussion will center on what a particular individual did to help a goal be achieved, which is kind of what you want, right? A side benefit of Scrum is that some team members will come to the review meeting with a list of every sprint task they owned in the past year. This is a level of detail that is not usually available to the waterfall manager or employee.

Another consequence of this approach is that you have a way to deal with the tricky corner cases of a) a star performer on an unsuccessful team, and b) a dud performer on a successful team. Many managers are not comfortable with rating someone highly just because her team has excelled, and those managers are even more uncomfortable rating a known and widely acknowledged star poorly just because their team did poorly. In this approach, you can find that even though a team performed badly, a certain individual really contributed in a larger-than-life manner to the team's attempts to achieve its goals. So, this approach can provide a stepping stone toward complete, team-based ratings. 

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!