Évaluer une équipe Agile

Publié par David Beaumier le jeudi 23 janvier 2014 à 16:11

Pour faire suite à mon billet précédent qui parle de l’évaluation des performances individuelles, j’ai pensé qu’il pourrait être pertinent de se questionner sur nécessité d’évaluer l’équipe dans son ensemble.  Alors qu’en développement Agile on mentionne souvent que la réussite de l’équipe prime sur les performances individuelles, les organisations s’attardent rarement aux équipes dans leurs processus d'évaluations de la performance. Peut-être aurait-on avantage à prendre un moment d’arrêt et à mettre sur pieds un système orienté sur les performances du groupe.

Par exemple, pourquoi ne pas mettre en place des mesures précises de certains aspects que l’on souhaite renforcer? Souvent, il peut être assez simple de le faire, quitte à ce que la collecte soit semi-automatisée (un chiffrier, par exemple).  Voici quelques facettes que l’on pourrait évaluer assez facilement :

  • Variation de la vélocité de l’équipe;
  • Nombre de stories non terminées dans le sprint;
  • Métriques sur la qualité du code;
  • Nombres d’éléments bloquants ouverts/fermés dans les sprints;
  • Niveau de précision des estimés de l’équipe;
  • Nombre de bogues en production et sévérité de ceux-ci;
  • Respect des standards de développement;
  • Valeur d’affaires de chacune des livraisons.

Jurgen Appelo, dans son livre Management 3.0, suggère de mesurer l’évolution des performances dans le temps et d’établir des comparaisons. Une augmentation de 15% de la vélocité par rapport à l’an dernier peut être un indicateur plus pertinent d'améliorations dans l’équipe que de simplement établir une moyenne annuelle de N points/Sprint. 

En plus des mesures quantitatives, on ne peut se passer des mesures qualitatives. Elles apportent un éclairage différent sur les performances et l'état de l'équipe en général. Voici quelques axes possibles d'évaluation:

  • Niveau d'auto-organisation
  • Confiance mutuelle
  • Niveau d'entraide et de partage des connaissances
  • Évolution du moral des membres de l'équipe
  • Recherche du consensus
  • Désir de s'améliorer individuellement et collectivement
  • Taux d'absentéisme

Là-aussi, on peut les collecter relativement facilement ces mesures, pour peu qu'on s'en donne la peine. Par exemple, plusieurs outils permettent de bâtir facilement des sondages anonymes et d'en compiler les résultats.

Quand et comment évaluer?

En agilité on parle souvent de réduire la boucle de rétroaction afin de pouvoir fréquemment ajuster le tire et améliorer nos façons de faire. En se basant sur ce principe, je crois qu'il est aussi pertinent de procéder à l'évaluation d'une équipe plusieurs fois par an qu'il l'est de passer d'une livraison annuelle à des livraisons mensuelles. L'évaluation peut prendre plusieurs formes, mais devrait débuter par l'établissement d'objectifs avec l'équipe. En tant que gestionnaire, à quoi vous attendez-vous de l'équipe? Quelle genre de résultats escomptez-vous pour la prochaine année? De l'autre côté, quelles sont les attentes de l'équipe? Quel niveau de performance souhaitent atteindre les équipiers? Quels aspects souhaitent-ils revoir et améliorer? Attention à cette étape de ne pas confondre les objectifs de performance avec le carnet de produit. Les objectifs doivent être en lien avec l'équipe plutôt qu'avec le produit.

Il existe plusieurs façons possibles de mettre le tout sur pieds. Je suggère d'y aller assez simplement pour débuter. Pourquoi ne pas tenir une rencontre regroupant équipiers et gestionnaire(s) afin de comparer les deux points de vue et produire une liste d'indicateurs qualitatifs et quantitatifs à mesurer. Par la même occasion on peut s'entendre sur la source de chacune des mesures sélectionnées et choisir la fréquence de la collecte de celles-ci. Si votre équipe fonctionne par cycles de livraisons de quelques mois, (3 cycles et plus par an) il peut être intéressant de faire coincider la fin d'une livraison avec la période d'évaluation.

À partir du moment où les objectifs à atteindre sont connus d'avance par toutes les parties, l'équipe devient apte à s'évaluer elle-même. Les équipiers pourraient fort bien intégrer cet aspect à la cérémonie de rétrospective d'itération. En revenant sur ses objectifs en cours de rétrospective, l'équipe est alors portée à réfléchir sur les différents éléments qui affectent, positivement ou négativement, l'atteinte de ceux-ci.

Interpréter les résultats

Un gestionnaire, moins impliqué émotionnellement que les membres de l'équipe, pourra avoir une vision différente et intéressante sur les performances globales de l'équipe. Avec le recul, il est probablement en mesure de déceler des enjeux dans la dynamique d'équipe ou au niveau de son organisation. L'interprétation que fera le gestionnaire des données colligées risque aussi d'être teintée par sa vision des enjeux organisationnels. Dans tous les cas, il importe de s'en tenir à la liste d'indicateurs identifiés au départ et d'être le plus objectif possible.

Qu'il s'agisse de mesures qualitatives ou quantitatives, il est important en cours d'analyse de bien distinguer les tendances systémiques des événements ponctuels. Un taux d'absentéisme qui augmente durant la saison de la grippe est probablement ponctuel (Pierre a transmis le virus à Josée, qui l'a ensuite transmis à Serge et ainsi de suite). Toutefois, si vous remarquez une augmentation de l'absentéisme la semaine qui suit chacune des livraisons, il y a peut être lieu d'en chercher la cause.

Aussi, petite mise en garde : il est toujours préférable de ne pas se baser sur une seule mesure pour tirer des conclusions. Mettez-là toujours en contexte. Par exemple, si on ne mesure que le nombre absolu de builds brisés par une équipe on oublie peut-être que celle-ci a une plus grosse base de code ou un nombre plus grand de développeurs et qu’elle a ainsi démarré plus de builds d’intégration continue qu’une autre. Il pourrait être plus judicieux de mesurer le ratio de réussite de builds en pourcentage. En anglais on dit « Be careful what you measure because that is what you are going to get », tel qu’illustré ci-dessous.

Source: http://www.axosoft.com/blog/2012/08/23/measure-agile-metrics-that-work/

Impliquer (encore) l'équipe

Une rencontre avec l'équipe devrait avoir lieu afin d'échanger sur l'interprétation des résultats. Comment l'équipe et le gestionnaire perçoivent-il chacun ces données? Y-a-t-il un écart entre les deux points de vue et pourquoi? Si l'équipe tient une rétrospective de livraison, parfois appelé rétrospective jalon, il est possible de réserver à l'avance une période de temps pour cet échange à l'intérieur de cette activité.

Peu importe la formule que vous retenez, il est important de prendre le temps d'identifier ce qui peut être mis en place pour traiter les écarts entre les objectifs et ce qui a été mesuré. Une équipe qui a tenu compte de ses objectifs au cours des rétrospectives d'itérations aura sans doute des pistes à suggérer et pourra peut-être même fournir un état de situation sur les moyens qu'elle a tenté pour adresser la situation. Est-ce que le gestionnaire peut venir en appui en faisant une intervention auprès d'intervenants externes à l'équipe? Est-ce que d'autres équipes au sein de l'organisation vivent la même situation? Auraient-elles avantage à échanger à ce niveau? Autant d'aspect sur lesquels le gestionnaire peut intervenir pour aider l'équipe à mieux performer.

Références

En terminant voici quelques références additionnelles pour vous permettre d'approfondir le sujet.

Mots-Clés :
blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.