The annual performance review sucks; try an agile appraisal!

Recently, at work, I was asked if I knew anything about Agile Appraisals. I had to admit that I didn’t, so I went and did some research. The first thing I found was a Wall Street Journal article called ‘Get rid of the performance review!’ from Samuel A Culbert, who is a professor at the UCLA School of Management. It’s an interesting read and sparked some ideas about what an agile review process should be.

I’ve taken some queues from the article as he talked a lot of sense, and wrapped an agile spanner around it.

Agile Appraisals

NOT the Holy Grain
As anyone who has seen Indian Jones and the Last Crusade knows, this is NOT the Holy Grail - Picture by Eddie Van W

The key is in the name, ‘agile’. We should turn to the holy grail; the 12 principles and four core values of the agile manifesto when thinking about how to appraise people people in our department. The four main points to take from the manifesto when thinking about appraisals, I think, are (paraphrased for context):

  • People and interactions over processes and tools
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behaviour accordingly.
  • Continuous attention to excellence enhances agility
  • Simplicity is essential

So, with this in mind, we can see what an agile appraisals needs to:

  1. Dispense with forms and formality and concentrate on the conversations;
  2. Look at how the team can work better together.

Individual agile appraisals

In individual appraisals, the ‘team’ are the boss and his/her subordinate. The boss’ focus of an appraisal should switch from the traditional “How are you performing for me?” to, “How can we work better together?”. The idea is that, the appraisal is about doing things that make the relationship between the boss and subordinate better and allowing the subordinate to appraise themselves. What do they need to do to make their input more valuable and what do they need from their boss?

Learning happens here
Learning happens here - Pix by shuichiro

This could be in terms of more training, guiding, coaching, tutoring or it could also be in terms of their relationship “I need you involved more in what I’m doing.” or “Help coach me on unit testing”. The subordinate should talk about how they’re going to make the relationship better and the boss should reply with “How are you going to do these things and, more specifically, how can I help you do that?”. This also has the benefit of reinforcing the Stop, Start, Continue idea of appraising your boss.

The whole idea here is to inspect and adapt, to spend some time reflecting how things are going and suggest and then try some ideas for the next period which reinforce the idea of a ‘team’ relationship between boss and subordinate and to ensure that the subordinate improves on issues that are important to them as well as being beneficial to the greater good of making quality software.

Bare this in mind during any appraisal: “Given who I am and what I am learning about this other individual, what is the best way for us to complement each other in getting work accomplished with excellence?”

The appraisals should be regular, at least once a quarter and last no longer than one hour. An appraisal can also be arranged at a convenient time for both boss and subordinate if either feels that their working as a team is suffering for any reason or that something that was agreed isn’t working or needs a tweak. The notion of ‘annual appraisals’ is absurd in this context.

Team agile appraisals

The team gather to reflect
The team gather to reflect - tiarescott

Team appraisals can be run in the same way. These shouldn’t be confused with the sprint retrospective. The team appraisal is where the whole team gathers in one place for a time (not sure if a time box is relevant here, I think it should be no longer than half a day perhaps, but no less than two hours) and in turn, each person works on the mantra above (“Given who I am and what I am learning about this other individual, what is the best way for us to complement each other in getting work accomplished with excellence?”), says how they feel they could improve to benefit the team and then the team provides feedback on what the team member said and perhaps offer any help, or suggest ways in which the team member might meet that improvement.

This is not an opportunity to bitch and moan. This is an opportunity to inspect and adapt and reflect on how the employee works within the bounds of their team. This is like a retrospective in many ways, instead of being about the process, however, it is about themselves.

They have the option of having their manager present, but it isn’t essential and if they don’t want them, they should not be forced to have them. The team appraisal should happen BEFORE the individual appraisal, this will give the team time to reflect honestly on how they feel they need to improve without fear of reprise, and then take this to their individual appraisal, hopefully without modifying their feelings too much before they sit with their boss.

Pay Reviews

Wait, what?
Wait, what? - Toban Black

It should be made explicit that annual appraisals are nothing to do with pay reviews. Appraisals are NOT for showing off how wonderful the subordinate is, no one writes things down they’ve done all year, they just get on with their job and do the best they can. If the appraisal was about that, the boss and subordinate would be working at cross purposes: the boss wants to talk about how the subordinate can improve and the subordinate wants to talk about all the great things they’ve done. The pay review meeting (if there even IS one) should be entirely separate.

The appraisals are about improving working relationships, not about money. I can’t stress how important this is. Without this explicitly stated, it will undermine the usefulness of the appraisal.

Another issue to think about when using money as a motivator is that it will only work in a narrowly defined way. People will do EXACTLY what is asked of them in order to get the bonus, or the payrise. They will do nothing more and nothing less, just what is required to pass the test and win the prize. Mary Poppendieck had this to say:

Using money as a motivator is like playing with dynamite because money is a VERY effective motivator.  Monetary rewards motivate people to do EXACTLY what is being rewarded – not necessarily what the organization intended to reward, but EXACTLY what is being measured to generate the reward.   Therefore monetary motivators have a long track record of generating unintended consequences.  If there is any apparent competition for the money, money motivates people to get as much as they can for themselves.  Thus monetary motivators have a track record of suppressing collaboration.  Finally, bonuses for performance rapidly come to be an expected part of the landscape, replacing passion and dedication as motivators .  These are things you probably cannot change about using money as a motivator.
Mary Poppendieck

Traditional Appraisals

Annual appraisals or performance reviews are supposed to be an objective evaluation of the employee that helps with determining payrises derived from performance and to let the employee know where they can improve. In reality, this is not a majority of peoples view; most folks see appraisals as a waste of time: they are dispiriting and foster resentment, cynicism and inherently dishonest, instead of promoting honesty and candour. Reviews are political and subjective and create a chasm in boss-employee relationships. The link between pay and performance is tenuous at best and they are in no way objective. Would two bosses give you the same review?

7 thoughts on “The annual performance review sucks; try an agile appraisal!

  1. I’m curious what your propose as far as actual pay reviews and compensation levels then?

    Certainly this is an important topic.

    Working for a company is a business transaction.

    The company is getting code, and in return they are paying money.

    The engineer is selling their time for money, and the company is selling their money for time.

    Therefore those rates need to be appropriate based on the value received.

    How do you look to deal with the compensation issues?


    1. Hi @Jordan, thanks for your comment.

      I don’t think it’s nearly as black and white as ‘company pays developer for code’, unless that developer is a freelancer or a contractor. There are many things that go into any developers decision to work at a company; anything from the kind of training they’ll be given, the freedom they have to learn and hone their craft by researching and getting involved in the community, attending conferences and seminars, the ability to work on personal projects during work hours once in a while, having a fridge full of beer and donuts in planning meetings, having consoles and TVs for use at break time (all of which happen at my company), as well as a raft of other things. It’s just as important for an engineer to invest in the company (time, effort) in order to for the company to recognise the need to invest in the engineer (training, hardware, software, conferences, beer). Any company that sits on it’s laurels and doesn’t train their engineers or provide the things they need to improve isn’t worth working for. It’s a two way thing, always, that both parties need to invest in each other. If you do the minimum, you’ll only get the minimum and, often, less.

      But, to answer your question about compensation. This can happen in another meeting, whereby the focus of the meeting is a pay review and not an appraisal. Both parties are focussed on the same thing. However, Steven Culbert (the Professor) stated that, in most cases, it will be market forces and the company/department budget which dictates what a company can offer in terms of compensation and not the ability or output of the employe and I agree.

      I can’t honestly say that I’ve written down everything of note that I’ve done this last year, does that mean that my input is any less worthy of a pay increase as the next guy? No, not at all, it just means I had better things to do with my time than record what I’ve been doing, or I haven’t actually done anything exceptional as I have been busy doing my actual job, or I’ve done nothing and slacked. In each of these cases, it’s hard to prove or disprove and, really, that’s where the problem lies.

      I don’t know the answer to this question, I can only offer the following:

      • Granting percentage pay increases once a year may causes rifts between your engineers (“What? How did he get a 20% rise? He does the same as me and I only got a 15% rise!” “Ah, but the market isn’t as good/it’s a slow month/the boss bought a boat.”) It doesn’t sit well, right?
      • As Mary Poppendeick says, employees will do only what is required of them to get the money if you set targets based on financial reward.
      • Rewarding teams is the best thing you can do, give everyone the same rise.
      • If you can’t do that, then just increase pay with inflation and offer other incentives/rewards, like training, new hardware, days out (that aren’t team building, no one likes that stuff!)
      • Be careful about awarding bonuses on successful completion of stuff (projects, release windows, sprints) it’ll become expected, regardless of how well the product/project did.
      • What would make your engineers happier? A small bonus or raise, or a new laptop? Don’t forget, they sit in front of their screens for 7-8 hours a day, maybe other rewards will work better.

      I think there might be another blog post in this! But I haven’t done much research or given it more thought than this comment, I hope you find something useful here though.

  2. Hi Mike,

    Couldn’t agree more with what you are saying. I believe that a key to getting your team motivated and engaged is to build better relationships within it and establishing a team focus on continuous learning and improvement. For each individual this is both “how can I improve myself” and “how can I improve the team” and it’s hard to do this at annual review time because it’s so disconnected from what you actually do at work. My experience with traditional annual reviews is that employees don’t value them, simply because they don’t help them and reviews/feedback needs to been more continuous – I’ve recently co-founded a startup Culture Amp ( which has set out to tackle this problem. Your philosophy here is nicely aligned with what we are doing.

    I especially like your idea of separating the agile appraisal from the team retrospective as this puts the focus back on the relationships between the collective team and the individual team member. In the past I’ve run similar exercises where I’d get the team together and ask them to collectively give me a ‘start’, ‘stop’,’keep’ (something they want me to start doing, stop doing, and keep doing’). I found this a really insightful exercise as it helped me better understand what I needed to do to support the team more, and what I was already doing that the team valued. It’s not always what you think.

    I’ve also witnessed teams really struggling with this exercise as they found it confronting getting feedback from the collective group in a team setting. Have you experienced this with your approach above? and what approaches have you taken to deal with it?


    1. Hi Rod, thanks for the comment.

      I’ve not put the team appraisal into play yet, it requires a great deal of trust and a smallness of ego. I need to work out how best to approach it first. Maybe alcohol will help! I’m thinking about doing it in a retrospective first and taking the first go.

      That said, most of my teams are already fairly self-appraising; they’re very blunt about it as well, so those with fragile egos sometimes come out worse for wear. But the unity in the teams is very strong and they do care about each other and how they work as a team, so it always works out for the best. Most engineers have a fairly thick skin anyway.

      I checked out Culture Amp, it looks good and I’ll suggest it to my company. Thanks!

  3. Thanks for the article – didn’t hear the term “agile appraisal” before, but that’s exactly what we do. I needed a rapid-feedback system at my previous company, so I focused on short cycles, peer-based feedback, etc. It all amounted to this process:

    As a result, I ended up setting up a new company around this approach:

    Let me know if you’d like us to set you up with an account so that you can play around with our approach.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s