Money and self organized teams

Managing a self-organized team is a challenge... especially when it comes to salary. On one hand side we can not leave it  up to the team to decide how much their salaries will be raised. On the other hand asking the team for an opinion about given team member when it is time for his annual appraisal is so obvious that even if the team wants to be honest and is mature, the opinion may be skewed. It seems that there is no easy way out from this situation.

It seems that the only way is to leave it up to the manager to decide but a situation when a salary raise depends on one person only leaves a room for an abuse and by definition does not even try to be objective.

Here is a proposal of an algorithm that can be used to calculate a salary raise in a self organized team. An algorithm that promotes team-work, tends to be as objective as possible, does not introduce "an acid atmosphere" in the team but on the other hand side it gives precise numbers.

According to my model salary raise is composed out of two factors:

R = R₁ + R₂

1. (R₁) Inflation + Salary ranges

To compute this part (R₁) we can employ an equation for a restoring force
I - inflation factor
k - restoring factor
s_low - lower boundary of a salary range
s_high - higher boundary of a salary range
s_mean  = (s_high + s_low)/2 - mean of a salary range
s_curr - current salary
k = I / (s_high - s_mean)

if (s_curr < s_high) {
    R₁ = I - k * (s_curr - s_mean)
} else {
    R₁ = 0
}

Short analysis:
- if you are below them mean of your salary ranges then this restoring force will pull you up, you will get an extra boost as you are underpaid
- on the other hand if you are over the mean of your salary ranges this factor in the most extreme situation (s_curr >= s_high) will be equal to zero (never negative)

2. (R₂)Performance factor

Everyone's opinion, appropriately gathered and analyzed compose the core of this factor (weights can be applied, but to be honest, in order to make the process as fair as possible I wouldn't introduce them). Just for the sake of this example let's assume that we have two teams cooperating with each other and every team consists of 7 people.

Step1. you ask every person to put all others in a row, starting from the one she likes to work with the most.

After this step is taken you have [7 (team1)+ 7 (team2)] 14 lists with [7 - 1 (all team-mates except author of the list) + 7 (all mates from the other team)] 13 names each.

Step2. you take all the lists together and sum them up in a way that if a given person is the last person on a given list you assign 0 points, if a person is at the first place on a given list she gets 12 points.

After this step is taken you have one list with pairs of names and score / weights.

In our current example you can simply compute that a given person can at most get score of 12 (points) * 13 (lists) = 156 points.

Having such a list and a budget for salary raises it is very easy (just by using a proportion) to compute how much of a pay raise a given person should get. If you'd like to take under consideration for example client's opinion with a higher weight (let's say 70%) you can ask client to assess every person from both teams by assigning a number c_i from a range 0..156 (or you can perform a simple normalization of 156 down to 100, which would probably be more intuitive for a client). 

c_i - weight of an i^th person assigned by a client
score_i - weight of an i^th person got directly from lists
w_i - final weight of an i^th person

w_i = 70% * c_i + 30% * score_i

B - budget for salary raises
s_i - current salary of an i^th person

 

 

Advantages:

1. By combining subjective opinions of all people that co-work with a given person you get the opinion that is the closest to the objective one.
2. This algorithm promotes team-players over individualists
3. It is easy to employ additional weights if needed

Disadvantages:

1. Being forced to put your team-mates in an order usually creates a dissonance (especially putting someone on the last position) - that's why there should be another process of giving feedback introduced in the team so given person knows what (s)he should be working on. In that way being fair with each other we encourage ourselves to grow and develop.
2. It is best if an appraisal process is triggered for everybody simultaneously, other way it is possible that people being constantly forced to put their team-mates in a row would become frustrated.

 

Step-by-Step simulation

Team of 6 people + client:

Alex (Senior engineer): 1000$  
Jane (Senior engineer): 900$
John (Junior engineer): 500$
Mark (Principal engineer): 1600$
Anna (Junior engineer): 800$
Barbara (Senior engineer): 1200$

Junior engineer salary ranges: 500$ - 900$
Senior engineer salary ranges: 800$ - 1200$
Principal engineer salary ranges: 1100$ - 1500$

Inflation: 5%
Budget for salary raises: 600$

Alex's list:  Jane, John, Mark, Anna, Barbara
Jane's list: Alex, Barbara, John, Anna, Mark
John's list: Alex, Mark, Barbara, Jane, Anna
Mark's list: John, Alex, Anna, Barbara, Jane
Anna's list: Barbara, Alex, Mark, Jane, John
Barbara's list: Anna, Jane, Mark, John, Alex

Alex: 4 + 4 + 3 + 3 + 0 =14
Jane: 4 + 1 + 1 + 0 + 3 = 9
John: 3 + 2 + 4 + 0 + 1 =10
Mark: 2 + 0 + 3 + 2 + 2 = 9
Anna: 1 + 1 + 0 + 2 + 4 = 8
Barbara: 0 + 3 + 2 + 1 + 4 = 10

Total number of points possible to get: 4 * 5 = 20
After normalizing scores to range 0..100 we have:

Alex: 70
Jane: 45
John: 50
Mark: 45
Anna: 40
Barbara: 50

Client's opinion about every team-mate:

Alex: 80
Jane: 75
John: 60
Mark: 65
Anna: 90
Barbara: 80

Final score every person obtains (having in mind that we value clients opinion more [70%]):

Alex: 0.3 * 70 + 0.7 * 80 = 21 + 56 = 77
Jane: 0.3 * 45 + 0.7 * 75 = 13.5 + 52,5 = 66
John: 0.3 * 50 + 0.7 * 60 = 15 + 42 = 57
Mark: 0.3 * 45 + 0.7 * 65 = 13.5 + 45.5 = 59
Anna: 0.3 * 40 + 0.7 * 90 = 12 + 63 = 75
Barbara: 0.3 * 50 + 0.7 * 80 = 15 + 56 = 71

After putting all equations together we obtain following values:
Alex: 12,85%
Jane: 14,23%
John: 15,81%
Mark: 6,02%
Anna: 10,15%
Barbara: 7,24%

Statement coverage .vs. Branch coverage .vs. Path coverage

This post is for these who would like to prepare themselves for ISTQB exam and have difficulties with understanding the difference between various types of coverage. Let's consider following piece of a code:

public int returnInput(int input, boolean condition1, boolean condition2, boolean condition3) {
  int x = input;
  int y = 0;
  if (condition1)
    x++;
  if (condition2)
    x--;
  if (condition3)
    y=x;
  return y;
}

Statement coverage
In order to execute every statement we need only one testcase which would set all conditions to true, every line of a code (statement) is touched.

shouldReturnInput(x, true, true, true) - 100% statement covered

But only half of branches are covered and only one path.

Branch coverage
You can visualize every "if-statment" as two branches (true-branch and false-branch). So it can clearly be seen that the above testcase follows only "true-branches" of every "if-statement". Only 50% of branches are covered.

In order to cover 100% of branches we would need to add following testcase:
shouldReturnInput(x, false, false, false)

 With these two testcases we have 100% statements covered, 100% branches covered

Path coverage
Nevertheless there is still a concept of path coverage. In order to understand path coverage it is good to visualize the above code in a form of a binary tree













As you probably see the above two testcases cover only two paths t-t-t and f-f-f while in fact there are 8 separate paths:
1-2-3
t -t -t - covered with testcase 1
t -t -f
t -f -t
t -f -f
f -t -t
f -t -f
f -f -t
f -f -f - covered with testcase 2