Rétribution salariale

Lors de l'entretien annuel, les trois axes suivants sont souvent évoqués :

  1. la progression des compétences individuelles;
  2. la contribution au succès de l'entreprise;
  3. la négociation salariale [1].

Le dernier élément est souvent en fonction des deux premiers. Parfois, l'augmentation est liée à l'effort fourni (elle reste jusque 22h tous les jours), d'autres fois à la compétence (il fait le travail en 2h au lieu de 5h par d'autres [2]), parfois encore à la compétence supplémentaire acquise (elle met 1h là où il lui fallait 2h). Il y a évidemment d'autres facteurs : le niveau d'indispensabilité, la visibilité de la personne, etc.

Gérer une augmentation dans un contexte traditionnel est donc déjà compliqué.

Salaire de l'individu / collectif ?

individu.jpgDans un contexte agile, l'ensemble de l'équipe tourne à peu près au même rythme soutenable. L'effort est donc le même ? Si on fournit le même travail, comment se fait-il que l'on ne soit pas payé pareil ? Les années d'expérience l'explique mais peuvent être incomprises.

L'ensemble de l'équipe travaille ensemble, ce n'est plus simplement telle personne qui s'occupe de telle tâche. Non seulement l'équipe tourne dessus, mais en plus elle binôme. Il n'est pas évident de distinguer les compétences des uns et des autres. D'ailleurs le faut-il ? Encourager les succès individuels (par des augmentations salariales) va à l'encontre de l'idéal de partage et de monter en compétences ensemble. Cette démarche n'incite pas non plus à la transparence et à montrer les problèmes.

Pour autant, donner la même augmentation à tout le monde ne me parait pas une bonne idée non plus. Cette égalité peu équitable peut démotiver les éléments moteurs, voire les faire partir. S'il s'agit d'un pourcentage, les mieux payés creusent de plus en plus l'écart; si c'est un montant fixe, les mieux payés ont l'impression d'avoir une baisse. Une piste serait d'évaluer les "efforts" à travers l'implication, les "compétences" par la pro-activité et la levée de problèmes.

Un intervenant à la table ronde disait consulter d'autres directeurs afin d'avoir des avis extérieurs. Le fait d'augmenter le nombre de regards donnent un effet miroir et oblige à défendre les cas. Un autre se donnait comme critère de ne pas avoir honte s'il fallait les publier. Un dernier disait au contraire, qu'il aurait honte de les rendre publique car il a parfois fallu "retenir" des personnes.

Le dernier axe est d'éviter ces questions en passant par des intermédiaires : la prestation. Si la SSII paie suffisamment ses salariés, on s'en sort bien sans avoir à gérer des problèmes d'équité et de motivation. Dans le cas contraire, c'est raté. Je pense à ce scrum master qui me disait que chaque année telle SSII sapait le moral des ses prestataires sans qu'il ne puisse rien y faire.

Augmentations

Dans le schéma classique, c'est en changeant d'entreprise ou de poste que l'on peut avoir un bond salarial. Dans l'agilité, il y a moins de paliers : développeur agile, développeur agile sénior, scrum master ou product owner, directeur de projets ? Petit panorama des pratiques :

  • toujours un peu au dessus du marché;
  • toujours le maximum du marché, quelque soit les résultats de l'entreprise, comme à Netflix [3]. Il y a ainsi peu de risques de départ qui reviendrait à une baisse de salaire. C'est également un facteur de motivation (c'est mieux qu'ailleurs). En pratique, il y a finalement peu d'augmentations et pas de variable, juste des "big salaries";
  • variable selon succès du projet en principe. Sans parler de la difficulté à définir le succès, la notion de "récompense" est dangereuse et créer des effets pervers;
  • en fonction de l'effort T / T-1, à l'effort Individu / groupe, au succès individu / groupe ?
  • une demande d'augmentation est soumise en proposition à tous les salariés de l'entreprise. Il n'y a pas d'entretien annuel;
  • chaque salarié décide de son propre salaire sous condition de la rendre publique [4] . Cela limite les injustices car vis à vis des autres, un salaire élevé pour soi limite le salaire d'un autre. Personnellement, j'ai un peu de mal à y voir un système qui peut marcher partout, à moins que les salariés soient aussi actionnaires. Le droit de décider de quelque chose d'aussi déterminant s'accompagne d'un risque à prendre. On a son mot à dire quand on est engagés, comme le cochon;
  • même idée mais l'entreprise est une coopérative ou SCOP. Motion twin, éditeur des jeux Labrute.fr et Hordes.fr ont adopté ce fonctionnement [5].
  • dernière variante : les salariés ont connaissance du budget et doivent se le répartir entre eux.

Parcours professionnel

parcours.pngLe métier de développeur est souvent vu comme le premier jalon d'une carrière, pas une fin. "Je ne vais pas rester développeur toute ma vie" est une phrase assez courante. Ce métier n'est pas valorisé comme aux Etats-Unis par exemple. La majorité des jeunes diplômés ne pensent qu'à devenir chef de projet. Dans un environnement agile, le parcours professionnel est plus flou, il n'est pas tout tracé. Cela peut faire un peu peur, on ne sait pas où on va.

Quand un désir de changement se manifeste, il peut s'opérer au sein de l'équipe sans qu'il n'y ait à passer par les ressources humaines. Chacun peut spontanément décider de se concentrer sur telle technologie, de faire du suivi de projet, du scrum mastering, de gouter à tout. Il peut même changer d'avis et réessayer autre chose. Ce côté officieux est souple mais peut manquer de concret s'il ne s'accompagne pas d'un titre\ [6]. C'est vrai, l'évolution est plutôt horizontale.

Par contre, il peut y avoir un manque de reconnaissance en dehors de l'équipe agile. Le développeur agile reste un "simple" développeur aux yeux du monde, alors qu'il peut faire de l'architecture, de l'expertise, du fonctionnel, de la planification, de la coordination. Toutes ces compétences peuvent être valorisées sur le CV mais le monde extérieur a souvent besoin d'avoir un seul interlocuteur. Dans la mesure où les informations sont bien relayées à toute l'équipe, je ne pense pas que ce soit un problème. Le tout étant de ne pas encourager ce mode là et de laisser les devs agiles répondre à l'extérieur le plus souvent possible. La communication au sein de l'équipe est alors déterminante pour assurer un suivi.

Si on veut clairement changer de poste, la voie suivante est scrum master ou product owner. Après, c'est peut-être directeur ? On peut avoir le sentiment de plafonner assez vite. Il y a aussi des postes de coach, d'indépendant. Et quand l'agilité sera mainstream ? A ce moment là, je continuerai de me dire qu'au moins, je m'éclate dans mon métier tout en apportant des petites pierres à l'édifice.

Le contexte agile est plutôt favorable à l'enrichissement individuel. L'équipe a des compétences variées et pointues, le tout est de donner à chacun des occasions de se dépasser.

Ressources