Pratique de l'utilisation du classement personnel de chaque membre de l'équipe dans le contexte de Scrum et SAFe

Dans cet article, je prévois de raconter comment, dans ma pratique, nous appliquons le classement personnel de chaque membre de l'équipe dans Scrum au cours du travail selon le framework SAFe

Beaucoup seront probablement d'accord pour dire que (surtout en Russie) chez nous les gens assez souvent s'efforcent de travailler (livrer le produit final dans le cadre de leurs compétences ou au moyen d'en acquérir de nouvelles) le moins possible et de gagner le plus d'argent possible. Avec la taille de l'entreprise, les possibilités pour cela semblent croître directement proportionnellement. En général, ce sont les différents profils RH qui travaillent là-dessus, en s'efforçant de toutes les manières de construire un bon système de motivation. On y trouve aussi les OKR et autres. Dans l'ensemble, il semble que tout cela vise l'équilibre de la charge de chacun au sein de la corporation et le confort de tous les groupes de parties prenantes/équipes de la corporation. Dans cet article, je partagerai une métrique que j'ai moi-même inventée et que j'applique dans l'équipe. Elle permet, me semble-t-il, de compléter les efforts des RH et des OKR en matière d'équilibre de la charge au sein d'une équipe concrète ou de voir le déséquilibre, respectivement. De plus, elle peut tout à fait s'étendre à une équipe d'équipes, je n'y vois pas de problème particulier.

Ainsi, en tant que Scrum Master, il m'est parfois assez évident que la charge dans l'équipe n'est pas équilibrée, certains travaillent pour deux, d'autres ne font rien (ce sont des formes extrêmes et, bien sûr, un problème sérieux, mais cette métrique montre aussi non seulement les formes extrêmes). Une telle situation m'est arrivée et je me suis demandé quelle métrique pourrait mettre clairement en évidence ce problème. Finalement, cela s'est traduit par un classement personnel de chaque membre de l'équipe.

Avant de décrire la métrique elle-même, j'aimerais aussi souligner une idée très importante, à mon avis. À l'heure actuelle, j'en suis absolument convaincu.

Les métriques doivent être construites sur la base des données que vous obtenez déjà. L'obtention d'une métrique ne doit pas obliger l'équipe à consacrer systématiquement plus de temps et à adapter son processus de livraison de valeur à la métrique elle-même. J'essaierai d'en parler plus en détail dans l'un des articles suivants.

Donc, un exemple de cas concret. Bien sûr, nous utilisons un tableau pour déplacer les User Stories selon les statuts de DOR (Definition Of Ready) à DOD (Definition Of Done). Il est chez nous virtuel (c'est-à-dire situé sur Internet via un lien. Notre équipe est aussi distribuée et les standups se déroulent via Skype d'entreprise précisément avec la diffusion du tableau.

Il est pratique pour un membre de l'équipe de s'inscrire comme participant d'une User Story afin qu'en utilisant le filtre par soi-même, on puisse rapidement ne garder que les histoires auxquelles il participe à un moment donné (le plus souvent, nous utilisons ce filtre lors des standups).

Ici aussi, j'aimerais préciser : cela ne signifie pas que ce membre de l'équipe ne peut pas participer à d'autres histoires (si, par exemple, lors du standup, l'un des membres de l'équipe demande de l'aide, il peut tout à fait devenir participant d'une nouvelle histoire ou, inversement, s'il sent que sa participation n'est pas requise, il peut cesser d'être participant d'une histoire.

Ainsi, pour calculer le classement de chaque membre de l'équipe, nous devons regarder sur combien de SP chaque membre de l'équipe influe. Dans notre cas, Arkadi influe sur 29 SP (histoires 1, 2, 5, 6), Tatiana influe sur 33 SP (participe à toutes les histoires), Vassili sur 23 SP (histoires 1, 3, 5, 6).

Fermé (DOD réalisé) chez Arkadi 5 sur 29 SP, chez Tatiana 6 sur 32 SP, chez Vassili 5 sur 23. Avec le tri, j'ai pas mal souffert et je suis arrivé à la formule de comparaison suivante de deux membres de l'équipe (team[i] - un membre de l'équipe et team[j] - un autre membre de l'équipe) :

Selon ce tri, nous obtiendrons le classement actuel des membres de l'équipe sous la forme suivante.

• 1re place. Vassili (Réalisé 5 sur 23)
• 2e place. Arkadi (Réalisé 5 sur 29)
• 3e place. Tatiana (Réalisé 6 sur 32)

Maintenant, générons toutes les données du sprint. Imaginons que le sprint dure 5 jours ouvrables.

• 1er jour
  

  

  
  1re place : Vassili (brûlé 0 sur 23)
  2e place : Arkadi (brûlé 0 sur 29)
  3e place : Tatiana (brûlé 0 sur 32)
  
• 2e jour
  

  

  
  1re place : Vassili (brûlé 0 sur 23) dynamique(1->1)
  2e place : Arkadi (brûlé 0 sur 29) dynamique(2->2)
  3e place : Tatiana (brûlé 0 sur 32) dynamique(3->3)
  
• 3e jour
  

  

  
  1re place : Vassili (5 brûlés sur 23) dynamique(1->1->1)
  2e place : Arkadi (5 brûlés sur 29) dynamique(2->2->2)
  3e place : Tatiana (5 brûlés sur 32) dynamique(3->3->3)
  
• 4e jour
  

  

  
  1re place : Vassili (8 brûlés sur 23) dynamique(1->1->1->1)
  2e place : Arkadi (8 brûlés sur 29) dynamique(2->2->2->2)
  3e place : Tatiana (9 brûlés sur 32) dynamique(3->3->3->3)
  
• 5e jour
  

  

  
  1re place : Vassili (23 brûlés sur 23) dynamique(1->1->1->1->1)
  2e place : Tatiana (24 brûlés sur 32) dynamique(3->3->3->3->2)
  3e place : Arkadi (21 brûlés sur 29) dynamique(2->2->2->2->3)
  

Ainsi, en utilisant cette métrique, on peut accumuler les statistiques personnelles de chaque membre de l'équipe et l'aider à tirer les bonnes conclusions. Par exemple, ici nous voyons que Vassili a planifié son temps de manière très judicieuse dès le début (c'est-à-dire que lors de la planification du sprint, il s'est mis d'accord avec l'équipe sur le volume de travail qu'il a effectivement réalisé.) Mais, en même temps, aurait-il pu d'une manière ou d'une autre aider les autres membres de l'équipe ? Peut-être que non, mais il vaut la peine de réfléchir à cette question avant la rétrospective.

Chez Tatiana et Arkadi, le problème est plus sérieux. Il est évident que dès le début, lors de la planification du sprint, ils se sont mis d'accord avec l'équipe pour participer à toutes les histoires et, en fait, n'ont pas pu honorer leurs engagements. Il vaut également la peine de réfléchir aux causes avant la rétrospective. Peut-être faut-il planifier moins pour soi, peut-être élargir ses compétences pour réussir à faire tout ce qui est planifié, d'autres solutions sont également possibles.

Ainsi, nous pouvons accumuler des statistiques non seulement sur toute l'équipe et non seulement sur un seul sprint, mais aussi sur des participants précis de la DEV TEAM sur toute la période et utiliser cette information pour l'amélioration continue de l'équipe.

En conclusion, je voudrais attirer particulièrement l'attention sur le fait qu'avant d'utiliser cette métrique dans l'équipe, un niveau de confiance déjà suffisamment élevé doit exister chez la majorité de l'équipe. De plus, je recommanderais de mettre fortement l'accent sur ce qui est primordial - l'absence d'heures supplémentaires et une activité confortable.

Nous nous concentrons sur une prévision correcte du résultat, et non sur la motivation à faire des heures supplémentaires pour occuper la 1re place. En fin de compte, cette métrique vise à améliorer la capacité de planification de chaque membre de l'équipe individuellement.