On my recent trip to China, I was surprised that the question I was asked most frequently was "How do I do performance management for agile teams"? I wasn't surprised that this was a question, but it's not usually the first one that comes up when people start to talk about making agile work in their companies.

Make no mistake: This is a big question for managers out there, and there are no simple answers. I do have a few practical tips and thoughts to share on the subject. My purpose in this article is to give managers of agile teams a few places from which to start developing their own approach to performance management for agile people.

It's almost amusing that out of the entire universe of people practices [1] that are a part of managing a company, the ones that managers seem most concerned with are a very few:

• How do I evaluate individual performance so I can give the right pay and bonuses to the right people?
• How do I identify star performers and keep them from leaving?
• How do I identify poor performers so I can "manage" them (usually implying "manage them out")?
• How can I support or reward team performance in my company's individual-oriented performance management system?

So, let's take a look at why this is a difficult question and then toss away the theory in favor of imperfect but workable approaches that you can use next week.

Performance Management Basics: Why It Doesn't Work

My bible on performance management is Abolishing Performance Appraisals: Why They Backfire and What to Do Instead by Tom Coens and Mary Jenkins. This book provides a good thought framework for this issue. Let's start there.

Why do we do performance appraisal? The authors suggest five different goals or functions that tend to be wrapped up in performance appraisal systems:

1. Improved results for the organization
2. Coaching and guidance for employees
3. Feedback and communication to employees
4. Compensation
5. Staffing decisions and professional development

As Bas Vodde and Craig Larman discuss [2] and Michael James [3] points out, most HR professionals do not seem to be aware that modern research has shown that the most popular performance management systems in use today not only do not achieve the positive results for which they were supposedly designed, but they actually tend to produce net negative results. These systems are in place because they seem like a good idea and everybody expects them to work and, gosh, they sure seem commonsensical.

Yet, Tom Coens and Mary Jenkins say, "The widespread practice of using individual performance appraisals to attain organizational improvement stems from the myth that better organizational performance will result from getting each person to do a better job. Substantial organizational improvement can only be achieved by improving the whole organization as a complex system." The authors show that current performance management systems do not do a good job on any of these functions, and they further suggest that, as a start, companies should design separate systems for each of these functions if they want good results. I am not an HR professional, so I rely on the authors' surveys of the literature when I (hopefully correctly) restate their conclusion that there is virtually no scientific data that supports the idea that performance appraisal as currently practiced by the vast majority of companies achieves any of the things that we all routinely believe it does. It's interesting to me that W. Edwards Deming's 14 Points for Management, published in 1986 [4], includes the exhortation to "eliminate management by objective" and "abolishment of the annual or merit rating."

Performance Appraisal: Satisfying Your Company and Doing the Right Thing

None of the preceding negates the fact that most managers and most employees today must participate in the annual productivity-sapping and spirit-deadening ritual of performance appraisal. Managers in organizations that have adopted agile practices have a particularly difficult problem: Nearly all performance-appraisal systems are based on principles that are diametrically opposed to the agile philosophy, and virtually nobody can opt out of those systems. What can a sympathetic and thoughtful manager do to make lemonade from the clear water of agile and the lemons of traditional performance appraisal?

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. 

Individual Development Goals

An area in which to be careful is individual goals. In an agile environment, individual goals are best used for individual development and not for meeting corporate objectives. Assign individual goals for individual development. Make sure individual goals are aligned with team goals.

Many traditional engineering goals for people are structured around owning a particular component or designing or implementing a component. These goals are inappropriate for an agile team member, because there is no room to redirect someone from contributing to the team's goal of building value to a non-value-oriented goal of completing a component.

A team member who is supposed to design and build a component will concentrate on the component and not on the feature that it supports. This monkey wrench can make the wheels of agile production grind to a halt, so these kinds of goals should be avoided. On the other hand, it's reasonable and helpful to desire that someone take the technical lead in implementing a user story or theme.

Individual Performance

Frequent 360 degree performance feedback is better than many alternatives. One manager in China said to me, "Scrum seems to hide the contributions of individuals, and I can't judge them as well." My first thought was "Well, what does that tell you?" No one on a scrum team knows better how each person is doing than anyone else on the team. Make use of that by trying 360-degree reviews. Doing them frequently takes away a lot of the sting and, after a couple of rounds, there will be no surprises left. Doing them outside the formal review process will allow people to comfortably give the kind of feedback that can really make a difference.

Here's how I did them. I announced to the team that we would do voluntary 360-degree reviews. Nobody was required to participate, but if you wanted feedback you had to give feedback for everybody else on the team, including the ScrumMaster and product owner. All feedback was handed in to the manager, who edited it together to make it impossible to determine who said what. Feedback was then delivered to each person directly and in private by the manager.

Team Behaviors

Most performance review systems include a passing nod to the skills that are important for individuals to be productive members of teams. As a reviewing manager, you have fairly wide discretion in weighing the importance of these traits, characteristics, and behaviors when you evaluate individuals. Use your discretion. Value highly the personal traits, characteristics, and behaviors of good team members.

Compensation

Trust me, your employees care about their annual appraisals mostly to the degree that the appraisal leads to raises. This obsession is the result of years of using appraisals to drive compensation decisions. The entire constellation of dysfunctional behavior that clusters around annual compensation decisions stems from a few cherished and incorrect beliefs:

• Small variances in compensation will drive large changes in behavior.
• Job satisfaction is largely due to compensation satisfaction.
• Bonuses will make people smarter.
• Rewarding one person does not demean another.
• The ability of an employee to deliver results for the company is largely under the employee's control.
• Raises keep the right people at the company.
• Individual behavior is the prime driver of organizational success.

It would take another article the size of this one or larger to properly discuss the foregoing assertions, so I won't attempt to do so here. Suffice it to say that none of the assertions above is true.

Minimize Compensation Differentials

Everybody wants to know how to accurately judge individual performance so appropriate compensation adjustments can be made. Does this actually make sense? Say I make a nominal $100,000 per year. Raises in most companies in most good years tend to be in the 3-5 percent range, so a really good raise for me would be 6 percent, or $6,000. That translates to $500 per month before taxes, which in the US might be around 30 percent, giving me a net improvement of $350 per month.

Would you say that $350 per month on top of a salary of around $8,000 per month really makes a big difference? Given that a bonus can't make you any smarter, what is the real incremental improvement that we expect to see after investing all of the time and effort into figuring out how to parcel out the available raise pool?

Now, let's put that raise in context. Most people want desperately to get a raise that is bigger than the one that their colleagues got. It turns out that most people feel they deserve it, because most of us think we're better performers than our colleagues. So, if I get my net $350-per-month raise and my colleague gets $250, what is the effect? I will feel a little bit good for a short time after the raise is given. My colleagues who got less than me will feel bad for longer than I will feel good.

How much simpler would it be to just pay people fairly and eliminate the jealousy around inconsequential pay differentials. One reason people put so much weight onto such small differences is that they are looking for signs of recognition and appreciation. Give them the recognition and appreciation all of the time, throughout the year, and you will find that the need for a symbolic but inconsequential raise will shrink.

Make the Outcome Be Correct

Most managers in most review and compensation systems have wide latitude when making final determinations concerning raises. A manager of an agile team should know more about everybody and more about the factors of team success than an equivalent manager in a command-and-control environment. Use the knowledge to make the right thing happen. 

Emphasize the Non-monetary Satisfactions of Agile

If you have a reasonably healthy agile implementation, your people will generally feel more positive about their jobs than they did in the pre-agile past. Find out if this is true and add it to the annual review picture. People enjoy having professional latitude. They enjoy having some control over their work life. They enjoy being able to contribute in unexpected and creative ways. They enjoy not being micro-managed. These and other benefits of agility count greatly towards overall employee job satisfaction and engagement. Arrange to have these positive aspects of agile be noticed, discussed, and mentioned during your annual performance review. Allow the performance review to include the employees' review of management and the company. You'll be surprised at some of the good ideas you will get from this kind of discussion.

Deal with the Outliers

All but the very most incompetent managers know which of their employees are the top performers and which are the bottom feeders. Neither Scrum nor waterfall nor lean nor agile makes this any more or less obvious. You can take action on your top 1 percent and bottom 1 percent (or even 5 percent) regardless of the methodology your teams use. Make sure your one or two true stars are kept happy, and don't be afraid to deal with your one or two laggards.

Summary

It's an imperfect world, and only consultants and authors can pretend otherwise. Real managers in real companies have to make tradeoffs every day in order to implement agile transformations and then to find a way to continuously improve. Even though performance appraisal is difficult and perhaps counterproductive, you have to do it. This article presents a few ideas on how to try to make the typical appraisal system work slightly better for agile teams. Start there and be creative. Do the best you can for your employees.

References

1. "People practices" is an agile way to name what are commonly called HR practices. I don't know where it came from, but I long ago learned that agile people prefer to be "people" instead of "human resources." I long for a beer and a companion who wants to debate the question "Can you ever be agile in a company that has an organization called 'Human Resources'?"
2. Larman, Craig and Bas Vodde, Scaling Lean and Agile Development (Addison Wesley, 2009), 267-268.
3. James, Michael, "What HR Doesn't Know about Scrum," Better Software, January 2010.
4. Deming, W. Edwards, Out of the Crisis (MIT Press, 1986), chapter 3.