The Agile Architect

Agility and the Annual Review

Of course you're great. Why do you need to have an annual review to tell your boss? Our Agile Architect talks about an agile approach to the employee review process.

• By Mark J. Balbes, Ph.D.
• November 24, 2014

Many companies have an annual employee review process that takes up a good portion of the holiday season. You may be experiencing this right now; I know that I am.

In most companies I've worked for, the annual review is tied to compensation and used to separate the wheat from the chaff in terms of performance of individuals in the company. Depending on the size of your company, the people deciding on your performance (and therefore your raise) may not even know who you are. Because annual reviews are performed annually, we may only get one shot at making a good impression, despite all the hard work throughout the year.

This leads to annual reviews that look something like this:

My Annual Review
Name: Dr. Mark J. Balbes, Ph.D.
Position: Agile Architect author
Tenure: 3 years

Name three successes this past year:

• Wrote 12 Agile Architect articles that all topped the "Most Popular Articles" section
• Acted as a panelist for a popular Agile webcast for ADTMag.com
• Stress-tested the editorial staff through a series of deliberate delayed-delivery exercises

Name three challenges from this past year:

• My deep understanding of agile software development makes it difficult for me to write short articles.
• My broad interests in all things related to software sometimes means I am writing about non-agile topics.
• My Agile Architect columns are so witty and enjoyable that I worry that my readers miss the point.

Agility and the Annual Review
Of course, my topics above are tongue-in-cheek, but finding ways to compliment yourself while supposedly exposing your weaknesses is an important skill when your raise is on the line.

But the agile world, with its philosophy of continuous improvement, looks at things differently. In this case, we are focusing on self-improvement, not compensation. So instead of a one-shot, all-or-nothing approach, let's see what the agile principles tell us.

If we are to follow the Agile Manifesto, we should eschew processes and tools in favor of individuals and interactions. Piling onto that, we should favor collaboration over contracts. This tells me that the review process should happen through a series of personal interactions, not some cold tool that everyone pours their thoughts into.

Written text is notorious for being able to be misinterpreted. No matter how excellent of a writer you are, typed sentences show no emotion, voice no inflection and have no physical expression from which to provide context. If I write the phrase, "This is an example of her best work," do you really know what I mean? Am I saying it with a smile and a happy tone, or am I saying the opposite. "If this is her best work, imagine how bad the rest of it is."

 

In order to have customer collaboration, we need to know who our customers are. Traditionally, this would be some manager or management team who must slog through all the reviews. In the agile world, we are looking for self-improvement, meaning the customer is both the person being reviewed and the people helping them to improve. They must be involved in this process.

Also, collaboration implies a longer-term approach to the review. One of the justifications for pair programming goes like this: "If code reviews are good, then continuous code reviews are better." We can apply this same logic to annual performance reviews. If an end-of-year review is good, a continuous review process throughout the year is better.

This is further emphasized by the agile principle of responding to change. Improvement doesn't happen overnight. When it does, it means that the person under review is now different. It makes sense to re-evaluate. At this point, it's no longer a review but a continuous improvement process for the individual.

Which brings us to the last point of the agile manifesto: valuing working software over comprehensive documentation. In this case, working software translates to a working self-improvement process. In order to know this, we need quantifiable metrics that tell us whether we are improving. This may sound cold, but as with all things agile, the metrics are there to help the team reflect on how well they are doing their work and help them get better at it. In this case, the team is the person under review and all of their colleagues that are helping them improve. In other words, the metrics help us improve the improvement process.

An Agile Improvement Process
From the above, we can derive the following qualities desired by an agile improvement process.

• Build a collaborative team focused on improving the individual
• Strive for continuous improvement of the individual throughout the year
• Strive for continuous improvement of how we strive for improvement throughout the year
• Emphasize human interactions
• Create measurable goals and objectives and track progress
• Adapt for change

Final Thoughts
This article is an act of pure and complete thievery. At my company, our Professional Development team is conducting an experiment that allows employees to play with different ways of performing their own review. Being good agile practitioners, the ProDev team is not dictating how this happens. The control is in the hands of the individual and their team of mentors, advocates and peers. The idea is to evolve a series of best practices that help all of us improve through a continuous, year-round process. It's been exciting to participate in this process at work. And yet, despite the many changes and improvements, one thing remains the same: I’m late turning in my own review.