Agile Zone is brought to you in partnership with:

David has enjoyed success using agile and lean techniques at several companies near Washington DC and San Francisco. He joined his first startup in 1999, and helped scale it to a 13 million dollar acquisition in 2006. He now brings entrepreneurial thinking into large organizations so that disruptive innovation can emerge. David is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

How to do Agile Performance Reviews

12.14.2012
| 4187 views |
  • submit to reddit
My last post of Performance reviews and Scrum left some readers unsatisfied. Brett send me an email where he comments:

So, while my heart leapt when I saw this link, sadly I was bitterly disappointed to discover that despite the fact its one of your most frequently asked questions, you didn’t actually answer it at all.

He then goes on to say:

While I don’t disagree that the performance-based pay has its downsides, like it or not, its simply the way the world works and no amount of philosophical debate and protest will change the fact that they are mandated by corporate policy … I would much rather see some actual practical/useful tips and techniques on how to do this effectively and fairly – do you have any insights you could share at all please?

I absolutely agree with Brett … he makes a fair point.

How to do performance reviews in an Agile environment?

Jeff Sutherland presents the performance review process that evolved during the first implementation of Scrum at Easel Corporation in 1993. It’s largely a conventional review process but differs in how the final rating is calculated. The final score has components of company rating (25%), team rating (25%) and individual rating (50%).

In a clever twist the rating scale includes information from external sources (e.g. “Trade journals are writing rave reviews about your work saying it is best in class.”), and limits the reviews influence to the middle of the range (4,5, and 6 on a scale of 1-10). Arguably this approach provides a more object measure by introducing information from external sources and focusing on the product over the individual.

Alan Altas has also written about performance reviews in “Performance Management for Agile People” published in the Agile Journal. Alan’s article is a much stronger move away from conventional reviews and he emphasizes a common team goal, 360 reviews and minimizing differences in individual compensation. He offers five points:

1. Give all of the members of an Agile team the same performance goals.
2. Assign individual goals for individual development.
3. Make sure individual goals are aligned with team goals.
4. Frequent 360 degree performance feedback is better than many alternatives.
5. Value highly the personal traits, characteristics, and behaviors of good team members.

And, he finishes some very sound advice:

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% and bottom 1% (or even 5%) 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.

Finally, I think Mary Poppendieck’s article “Unjust Deserts” from 2004 is still very relevant. It’s much broader than just performance evaluations and touches on compensation (pay) and promotions. The article provides a general overview of the entire system of performance reviews, and recommends some guiding principles to help understand the motivation of performance reviews within a Scrum environment.

One of the greatest thought leaders of the twentieth century, W. Edwards Deming, wrote that immeasurable damage is created by ranking systems, merit raises, and incentive pay. Deming believed that every business is a system, and the performance of individuals is largely the result of the way the system operates. In his view, the system causes 80 percent of the problems in a business, and the system is management’s responsibility.

Published at DZone with permission of David Bland, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)