Chapter 16. Appraisals and agile don’t play nicely

by Gary Reynolds

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 with 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 used as the basis for further discussion. Some systems have been directly linked to pay and promotion opportunities, whereas others have been explicitly decoupled.

One thing 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’d suggest that this is in direct conflict with the adoption and use of agile frameworks within the organization. Think about it:

• Agile emphasizes teamwork and cooperation 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 that direct and manage their own work, whereas appraisals involve the setting of objectives that traditionally come from the manager.
• Agile processes emphasize constant process improvement. Although this can be done alongside traditional appraisals, appraisals are geared more toward 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 to increase the value of each team member to the organization by expanding their skillset ian 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.
• Include team member feedback sessions as part of your iteration retrospective process, where you can directly discuss what people have learned.
• 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—when they’re most relevant.

What else can you think of?

Roy’s analysis

Think about the influence forces and the environmental motivation force. That’s the force that relates to company rewards and punishments for specific behaviors.

In essence this note shows us that yearly performance reviews can badly influence employee behaviors by rewarding selfish work and knowledge hoarding. The note also discusses how we can reward different kinds of behavior by changing how we ask our team to do things (pairing) and rewarding the right behaviors (measuring learning at individual and team levels).

Exercises

• How does your company or environment reward good or bad practices? For example, do people end up financially advantaged (bonus) by shipping poor quality, quickly? Do people get berated by their manager for refactoring instead of working on new features?
• List at least two good behaviors and two bad behaviors that you see people do, and how they’re rewarded or punished by the environment (mentally, financially, or in some other way).

GARY REYNOLDS 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.