Pas de note individuelle pour un travail collectif

En plus d'être contreproductif, c'est injuste.

Dans un billet récent, je reprenais les arguments d'Esther Derby contre l'évaluation individuelle, contreproductive pour l'équipe.

David Anderson trouve même que c'est mal. Il est évident que cela a tendance à démotiver l'équipe et à provoquer des frictions.

En plus, c'est souvent injuste. J'en ai eu l'expérience avec mes étudiants sur leurs projets. Ils travaillent en équipe et il y a eu des disparités dans les notes qui ont été très mal perçues. L'appréciation individuelle est basée sur une impression ressentie par les enseignants lors d'une revue ou d'une présentation et ce n'est pas toujours les plus impliqués qui se mettent le plus en évidence.

C'est pourquoi je propose pour l'année prochaine qu'il y ait uniquement une appréciation collective au niveau de l'équipe : toute l'équipe a la même note. A l'argument qu'on peut m'opposer en disant que c'est aussi injuste de donner la même note à toute l'équipe si certains ont beaucoup moins travaillé que d'autres, je rétorque :

  • qu'il me paraît impossible de définir des critères objectifs pour noter l'investissement individuel dans le travail collectif que représente un développement de logiciel,
  • qu'il existe assez d'évaluations individuelles par ailleurs.

Sans oublier de rappeler l'essentiel, qui est que l'évaluation individuelle est néfaste à l'esprit d'équipe.

Commentaires

1. Le mardi 31 juillet 2007, 14:39 par Frédéric Monjo

D'un côté la notation individuelle est nuisible à un bon état d'esprit de l'équipe c'est certain, mais de l'autre trop de "communautarisme" peut nuire à la productivité globale de l'équipe, chacun pouvant avoir tendance à se reposer sur les autres. Je pense qu'il n'y a pas de solution meilleure que l'autre, tout dépend de ce qu'on cherche à mettre en avant.

Dans le cadre des BE, je suis d'accord avec vous sur le fait qu'il y a déjà assez de notes individuelles par ailleurs : il est plus intéressant de donner l'occasion de développer l'esprit d'équipe et son autorégulation que d'employer la technique du bâton et de la carotte.

Si on réfléchit en termes d'équipe Agile, ScrumMaster compris, c'est aussi une des responsabilités de l'équipe vis-à-vis du Product Owner, qui est là pour parler produit, vision, releases, et pas des détails du quotidien.

2. Le mardi 31 juillet 2007, 16:05 par Brice Jones

Le problème se pose aussi de la même façon dans une équipe de développement en équipe: qui produit plus de valeur et comment l'identifier dans une équipe ? Ici, on ne parle plus de note mais de "gratification financière"...
Malheureusement, je ne peux pas "gratifier" toute l'équipe en même temps...manque de budget.

Je ne comprends pas pourquoi il n'est pas possible de diviser le budget alloué aux gratifications équitablement entre tous les membres de l'équipe. Cl.
Et bien, il faut analyser la situation agent par agent pour ce rendre compte de l'implication plus ou moins forte.
C'est le seul moyen que j'ai trouvé !

Esther Derby propose d'autres moyens dans le billet que je cite. Cl.