L'évolution de carrière dans les équipes Scrum

Hello les amigos !

J’ai un sujet débat à vous soumettre : quelle évolution de carrière possible pour les membres d’équipes Scrum ?

On a les fameux trois rôles :

  • Product Owner, qui peut prétendre à évoluer, tel un Salamèche en Dracaufeu dans Pokémon, en Product Manager. Plus de Discovery ou du moins, plus de hauteur sur le portfolio produits de l’entreprise, isn’t it ?
  • Scrum Master, qui peut prétendre à évoluer, tel un Carapuce en Tortank, en Coach Agile ? Plus de hauteur sur les équipes de l’organisation en général, y compris hors des équipes IT. Isn’t it ?
  • Developer : vu qu’il n’y a plus les fameuses et prestigieuses positions de « Architecte », « Tech Lead », « CHEF DE PROJET », à quelles évolutions peuvent-ils prétendre ?

Je suis curieux de vous lire ! :slight_smile:

Si la question était « quelle évolution de carrière est la plus logique ? », j’aurais des réponses sûrement similaires à ce que tu as pu exprimer. Mais ce n’est pas la question, donc je répond à la question posée:

Whatever the fuck they want.

Développ(eur|euse) Senior avec 6 ans d’expérience, et après ? (Hugo Lassiege et Dimitri Baeli)

Merci @Alexandre_Quercia, très intéressante conf !
Ce que je me demande, en mettant ces X titres de postes en face de Scrum (ou tout autre mécanisme de disruption de la chaine managériale), c’est comment les équipes agiles valorisent-elles un developer qui a largement plus « d’impact » (pour reprendre la conf) que les autres ?
Les mécanismes de reward individuel n’étant plus souhaités dans des sociétés au mindset agile, au profit de reward d’équipe, je me dis que ça peut froisser certains « vieux » dev de ne pas se voir rétribuer à leur juste valeur.

Comme tu dis @Samuel_Abiassi, au final, on en revient à ce que la personne veut. Si c’est de la rém., j’imagine que certaines disparités dans l’équipe sont acceptables. SI il veut un fameux « poste à responsabilité », je me demande déjà un peu plus vers quoi il peut s’orienter.

Le problème ici étant de définir « juste valeur ». Est-ce qu’on est dans une logique productiviste, objectivé à la ligne de code ? Est-ce qu’on est dans une logique ou celui ou celle qui a le plus de connaissance reçoit le plus d’argent (qui irait complètement à l’inverse de ce qu’on cherche à obtenir à savoir une équipe apprenante ou les savoirs sont partagés) ? Ou est-ce que l’idéal serait une équipe justement apprenante, et dans ce cas, le but étant que tout le monde monte en compétence, ces critères là serait plus inaptes qu’autre chose.

C’est quoi un « poste à responsabilité » ? En Scrum, tout le monde à des responsabilités qui sont déjà bien assez fortes.

Il y a quand même une différence entre un dev qui est responsable de son code et de ce qui tourne autour, un SM qui s’occupe d’une équipe de 5, un PO qui gère 1 ou 2 produit de 5/10 personnes, un RTE dans un release train de 200 dev, un PM qui synchronise 5 ou 6 produit multi-site, un CTO qui chapotte un département de 100 personnes, un coach agile « haut niveau » qui s’occupe de la migration agile d’une orga de 2000 personnes, etc…

Bref, OK tout le monde a des responsabilités, mais les enjeux ne sont pas les mêmes à tous les niveaux.

On remarque cependant que ce n’est pas forcément les « plus haut » placé qui sont les plus heureux, voir les mieux payés :grin:

1 « J'aime »

@Samuel_Abiassi c’est aujourd’hui facile de savoir ce que tu vaux sur le marché en tant que développeur. T’as X baromètres qui sortent chaque année pour donner les moyennes de rém. en fonction des années d’XP. Ce qu’on vaut par rapport au marché actuel en résumé. C’est ce que je voulais dire par « juste valeur » :wink:
Tu peux clairement pas dire à un dev qui a 10 ans de dev qu’il sera payé à même hauteur qu’un dev qui sort d’école, même si ils interviendront sur le même périmètre.

Je te répondrais qu’il y a des dev de 10 ans cons comme des balais et très mauvais qui sont là parce qu’ils sont planqués ou très bon en politique. En plus de ça, c’est tout à fait relatif vis à vis du contexte.

1 « J'aime »

J’ai l’impression qu’il y a une différence entre « rôle » et « métier », qui n’est pas visible ici.

On peut avoir le rôle « développeur » et avoir le métier « coach technique ».
On peut avoir le rôle « développeur » et être « tech lead ».
On peut avoir le rôle « développeur » et être « architecte solution ».

Je vois pas le problème ?

3 « J'aime »

bon ben c’est ce que j’allais répondre.

J’ajouterai « intitulé de poste » dans la différenciation

Un rôle, c’est un groupe de responsabilité dans un contexte ==> RACI

Un métier, c’est un ensemble de compétences acquises, exercées, et amélioration continue

Un intitulé de poste c’est une étiquette RH pour justifier un salaire. ← je troll mais c’est tellement pénalisant ces intitulés de postes qui te reviennent à la tronche par un « je suis pas payé pour ca »

Il y a aussi les « diplôme » (je suis -docteur-ingénieur-gradué-machin-brol- monsieur! )

En Scrum, l’équipe est multidisciplinaire pour composer avec l’ensemble des compétences nécessaires à accomplir sa responsabilité de livrer un incrément.

Les métiers, ca aide à ne pas devoir lister toutes les compétences « classiques » d’un métier".
Tout comme, les rôles ça aide à ne pas devoir relister toutes les responsabilités.

Le titre de poste, c’est entre moi et l’entreprise.

2 « J'aime »

Ce sujet a été automatiquement fermé après 2 jours. Aucune réponse n’est permise dorénavant.