Monthly Archives: February 2012

Performance Appraisal on Agile Projects

Over the last week I’ve had two people ask me about performance management and appraisals on Agile projects.  This post is to provide them with some answers and will hopefully be useful for others in the future.

One area where the adoption of Agile approaches often bumps up against established organisation structures and frameworks is in the realm of performance management of individuals.

There is a lot of research to show that many of the current performance management approaches are actually demotivating and harmful, especially in environments (such as on Agile project teams) where the most productivity and value comes from collaboration and teamwork.

Daniel Pink gave a fantastic TED Talk in which he examines the science of motivation:

In their book Craig Larman & Bas Vodde, discuss many of the problems inherent in the performance appraisal process, and how they actually destroy motivation and destroy team cultures – see “Scaling Lean and Agile Development”, Addison Wesley, 2009, pp.  267, 268

Even management guru W Edwards Demming advised organisations to “Eliminate Management by Objective”  and  urged “…abolishment of the annual or merit rating …”.  (Deming, W. Edwards (1986). Out of the Crisis., Chapter 3. MIT Press)

Michael James published an article in Better Software magazine entitled “What HR Doesn’t Know about Scrum” in which he summarises some of the key issues with traditional HR approaches and Agile (Scrum) practices.

The article can be found here: His key points are that many of the existing HR practices are derived from the era of Scientific Management and they don’t work for knowledge worker roles.   Individual performance appraisal drives behaviours that are contrary to team effectiveness:  “Team self-organization around business-driven goals will fall short when individuals also have goals of looking good for the boss or outscoring teammates in 360-degree peer review contests.

He goes on to discuss the importance of hiring for team cohesiveness rather than individual skills, ideally allowing the team to choose new hires themselves.  Yes, technical skills are important but more important is the ability of the team to jell and work effectively together.

Other commentators have written about the danger of individual performance reviews on Agile teams.  Esther Derby posts about the dangers of the review process, and she provides advice on addressing the common concerns among managers when looking at changing the review process.  (

She lists the most common  reasons for having performance appraisals and addresses concerns around them

  • Determining how much to pay people
  • Determining who to promote or fire
  • Helping team members understand how they need to improve

If organisations insist on retaining performance reviews there is some advice available from Alan Atlas in the Agile Journal.

He examines the motivation for performance management, discusses why they generally don’t work, and gives some possible approaches that could be used.  His key points for performance appraisals are:

  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.

Jeff Sutherland posted his approach to performance reviews and presents a possible approach for an appraisal process here:

Lean & Agile thought leader Mary Poppendeick has also written at length on the topic in this article where she examines the typical dysfunctions caused by the process, and provides guidelines for designing an effective performance management system.

Tara Hamilton-Whitaker of the Agile 101 blog has two posts discussing an Agile Balanced Scorecard, which can be used to assess a TEAM as a whole, rather than trying to assess the individuals against one another.

I hope this helps, and as always I welcome feedback.

Posted by Shane Hastie

Leave a comment

Posted by on February 26, 2012 in Agile