5 Whys is a blog about technical leadership in the software world.

Appraisals and Agile Don't Play Nicely

The following is a guest post by Gary Reynolds. Contribute your own here.

Gary is a Development Manager for a global software company, with particular expertise in transitioning teams from 'traditional' software development practices to more Agile ways of working.

Appraisals, performance reviews, 360 feedback, evaluations - call them what you will - have been present in organizations in one form or another for over 100 years. Over this time, the process has taken a number of different forms, depending on the current trends and the size of the organization.

I personally have experience of written evaluations where the employee has no input, various rating systems - where both employees and managers get to rate the individual - and written appraisals where the employee makes comments on their own performance that are then used as the basis for further discussion. Some systems have been directly linked to pay and promotion opportunities whereas some have been explicitly decoupled.

One thing that they all have in common is that they focus on the individual, their performance and what they've accomplished since the last review period. They encourage the individual to take credit for themselves and to compete against the other people on their team for recognition and a limited pot of money when it comes to bonuses and salary increases.

I would suggest that this is in direct conflict with the adoption and use of Agile frameworks within the organization.

Think about that:

  • Agile emphasizes teamwork and co-operation in order to successfully deliver a product, with individuals being prepared to take on any task that needs doing in order to complete the iteration and get to 'done'. Individual accountability, as valued by the traditional appraisal system, implies that individuals should be interested in taking the juiciest or most challenging tasks for themselves in order to prove their worth and progress within the organization.
  • Agile emphasizes the forming of self-organizing teams who direct and manage their own work, whereas appraisals involve the settings of objectives that traditionally come from the manager.
  • Agile processes emphasize continual process improvement and, while this can be done alongside traditional appraisals, appraisals are more geared towards making individual or process changes at review time.


Is there a case for abolishing appraisals altogether in an Agile environment? - well perhaps. The challenge is that individuals within an organization expect and deserve feedback on their performance.

Perhaps a step in the right direction would be for team leaders to make the appraisal process itself more Agile and encourage an environment where the annual review is replaced or supplemented with a system of continuous feedback and learning where individuals - in line with Agile - are empowered to self-organize their own career development. Here are some ideas to get you started:

  • Build learning and career development into individual user stories - perhaps in the form of a specific task that involves team members expanding their business domain knowledge. Alternatively, include time for learning tasks into your velocity calculations so you can increase the 'value' of each team member to the organization by expanding their skill set in a way that's relevant to their immediate task. Let the individuals drive and organize this learning process as they would a normal development task.
  • Encourage pairing (pair-programming for example) on tasks that help individuals to learn from those more experienced than them.
  • Include team member feedback sessions as part of your iteration retrospective process, where you can directly discuss what people have learnt.
  • Encourage individuals, on an iteration-by-iteration basis, to maintain a body of evidence that can be directly referenced at formal appraisal time. This will reduce the time taken to plan and perform the appraisal and encourages the recording of tasks at the time they happen, i.e. when they're most relevant.


What else can you think of?

Go see, ask why, show respect

Making your team manage their own work