The Problem of Measurement

As more and more projects shift to the Agile methodology more focus is put on the entire team’s performance and delivery. This in turn means it does no longer matter if you as an individual have completed all your assigned tasks if the team as a whole has failed to succeed. While the approach of “we’re in this together” is definitely a large step forward when delivering value and results it becomes problematic when managers are required to do individual performance assessments of each team member.

While I do not have the perfect solution I want to give some insight in my personal experiences and opinions on this topic.

There is no Team in I

The main problem with the situation is that Agile promotes “one team” thinking which is tremendously beneficial to the performance and success of a project. On the other hand high-performers want – and to some degree – deserve to be recognized for outstanding work. The issue of if and how to reward individuals in a team environment is a tough cookie on it’s own that I’ll skip in this context.

What I do want to emphasize is that in an Agile environment the individual rating of team members is made even tougher as you technically need to separate the contributions to the team result. Also the question comes up: “If I emphasize team results and team achievements, what do I set up as hard, measurable success criteria in the Performance Assessment?”.

For both questions there is no ideal, one-size-fits-all, silver-bullet solution. But there is perhaps a way to be both Agile and be able to recognize performance fairly.

Hard Facts for Everyone

When it comes to hard, measurable business results I would always recommend to do this on a team level. This means goals like release dates, quality metrics, X amount of leads converted into contracts, etc. should always be defined for the entire team. These global goals then go into each team members’ Performance Assessment goals. The important part is that everyone on the team has to have the same shared goals. It’s not okay to cherry-pick or let team members choose their own selection.

If you cannot define goals that can be applied to the entire team then it might be worth investigating why people with widely differing goals are put together as a “team”.

It might be preferable to openly discuss and define these goals in the entire team so that everyone can contribute. In the end it’s important that every team member can commit to the shared goals and be evaluated by them.

Using this technique you can enforce the “one team” spirit while at the same time laying hard ground rules for evaluation.

Going Soft

It’s pretty obvious that successful project work is a lot more than just following a set of defined, measurable goals. It’s also HOW the team approaches new challenges, works together and gets the value delivered.

This touches upon areas such as problem solving skills, inter-personal communication, knowledge-sharing and the general work values. As these things are less easy to define and may differ from the assigned/perceived role of a team member things will get difficult at this point. I would recommend splitting Soft Skills into two groups: General team rules and individual expectation.

The general team rules should encompass how the team approaches a given situation, it’s work ethic and conduct. This includes things like “We will share knowledge” or “We will identify the root cause instead of treating the symptoms”.

If you have defined the general team values when initially creating the team AND WRITTEN THEM DOWN – good job! If not it now would be a good time to have the team define these general values and write them down (e.g. as a poster on the wall) so it is clear HOW the team accomplishes it’s goals and goes about the daily work. You should make it clear that the team will be evaluated on each individuals follow-through on these rules.

It’s important to note that these rules should be a guideline and that it is okay and normal if people are not always 100% or even 80% on track – we’re still humans not machines.

For role-based expectations, e.g. if you have a team lead, architect or someone with a special role on the team you should define the expectations as you would with every personal goal – direct and in private.
As it is clear that these expectations are tied to the individual and the individual’s role this approach does not conflict with the general team rules and you can draw the line more clearly.

Matching Expectations with Reality

When it comes to comparing the expectations with actual results the approach largely depends on what you are evaluating. The hard, measurable team goals can be checked during sprint review and delivery gates. The approach will be more or less the same as with every other business goal. For the “Soft” values and skills things get very different very fast.

Any kind of evaluation of the softer goals requires experiencing how the team acts. This means attendance at the regular team events such as Scrum Meetings and Sprint Reviews is pretty much required. How will you evaluate somebody if you haven’t seem them in action? But by all means do NOT visit the meetings taking notes on each members performance! It’s more about getting a feeling where the strengths and weaknesses are. If you are not directly involved in the project because you are “just” the line manager make sure that you regularly check in with the project manager / product owner involved. Also make sure that the PM/PO understands what criteria you are evaluating team members on so you can get meaningful feedback and not just a general “performance was pretty okay”.

Another tool at your disposal are 360° reviews. These kind of reviews take in feedback from peers, managers, people-managed and the person in question to form a better picture of the performance. If you want to do this make sure you understand how the review process works as it is quite different from the regular manager-evaluates-employee approach and also be open about your intention to use it.

In the end you should be able to combine business results with feedback on the individual’s “softer” values to create an accurate evaluation without counteracting Agile’s spirit of teamwork.

The Model