Individual performance or team performance?

Question

In line with Scrum, a true self-managed team should be viewed and assessed only as a team. E.g. if the team is high performant, when we discuss about increasing salaries, each person in the team should get the same % increase.

But this is the ideal situation. In reality not everyone in the team contributes in the same way / same quality / same effort to the result.

Question:

1. Do you measure individual performance at all?
2. How would it work - if the case in your organisation - deciding salaries and rewards based on team performance?
3. Anybody actually functions in the ideal situation above? Where salaries are equivalent and increases are team-based?

How we do currently: we review each dev in a review circle (made of Seniors) and salary and compensation is made based on the review. The team metrics doesn't affect in anyway this (and it seems to be quite unfair).

Answer 1

One of the benefits of properly embracing and executing the Agile philosophy is truly collaborative teams, not a group of individuals assigned to work "together" (i.e. answer each others' questions) under a single manager. The team works toward creating quality, valuable products. Framing things on individuals can be an impediment to team development and maturation.

The majority of the goals need to be team oriented in order to facilitate the team concept. These are generally manifested in Sprint Goals. Limit scope and time to ensure quality and reduce risk. Focus on the team's short term mission. Creating and attempting to adhere to longer range planning will lead to disappointment. (see history)

Any individual goals need to be tailored to that person and not be based in what the team accomplishes. For example, achieving X story points is bad as an individual goal; it can also be bad as a long term team goal. (It also goes against the "maintain a constant pace" principle.) Instead individual goals should focus on items such as skill or education.

In the Scrum framework specifically, both the Development Team and Scrum team are to be self-organizing. Allow them to determine and address how each member contributes. This may not come easily at first, but once the team begins to perform together, they will be able to self-manage.

Bonuses and base pay increases should be based primarily on the team (see "Working software is the primary measure of progress.") with a splash of the individual improvement goals. Do not create a sub-team for making such decisions.

BTW, you need to point me to where The Scrum Guide declares your first statement and the following ergo.

Answer 2

I believe this may be the point where you have to make the distinction between self-organized and managed. In my organization the contributions of the individual to the team is as much of concern to management of the organization as it is to the members of the team. We have to make cultural assessments not just on working with the team but also with how the person works with the company. Although I do not use individual contribution metrics as a primary source of evaluation, I will look at an individual's contribution to see if they are aberrant before talking with teammates and other management when doing evaluations. Metrics can show an area of concern, such as a training need, or area excellence, such as providing an outlying level of contribution.

Our organization believes that teams are made of individuals with individual strengths and weaknesses. When doing evaluations for something as individual as compensation we believe that the individual is the important focus.

However, our organization does subscribe to Agile philosophies and methods, so we do look at the team as a whole when looking to make special awards. It is when we reward a group that they are all treated as equal parts of the whole team.

This philosophy is founded on the belief that to provide the best support to self-organizing teams, management has to understand the people in them. It's not something covered in The Scrum Guide, but it is covered in many management books, and we have to remember that teams work for a company.

Answer 3

If the agile teams are never going to change then rewarding them by team makes sense, but it seems more likely that in your situation there are enough people & teams for movement.

In that case it is essential that you identify high, medium & low team performers within those teams. This means that when teams are reorganized there is an opportunity to push developers who help make teams perform well into situations where they can cause best effect.

In development the high performers should be paid more & then stretched by being pushed out of their comfort zone so that they can help bring others along. So that in the end everyone is improved.

If a high performer seems to be consistently in low performing teams then there is a problem with how performance is measured.

But a high performer who consistently raises the game for the team they are in should be rewarded handsomely. The first indicator of personal performance should be team performance.

Answer 4

Individual performance should be recognised - otherwise high performing individuals may become demoralised and seek alternative employment. But recognition comes in many shapes and sizes, not just financial - so if your firm doesn't allow individual fiscal recompense, a simple verbal "well done" or "thank you" on a regular basis goes a long way to make up for it. Especially when done in public, or if followed up by an email too. Giving kudos and professional respect for someone's efforts massively boosts one's ego, and if you chat to the employee and explain the fiscal constraints you'll earn that person's respect, so it's a win-win all round.

This is all in addition to recognising team performance too - otherwise the entire team may want to leave. Praise the team, whether following agile / scrum or not.

Avoid the scenario whereby the team or individuals in it can say "I didn't even get a 'thank you' and that costs nothing" at all costs.