Compter les heures, c'est mal

Suite du débat…

Mon point de vue : trouver de l’intérêt dans le comptage des heures, c’est probablement le symptôme d’une mauvaise application de Scrum.

Suite à mon billet sur les tâches chiantes, Rémy a fait un commentaire sur l’intérêt pour lui de relever le temps passé. J’ai fait un nouveau post sur le relevé des heures en donnant quelques arguments contre cette pratique. Rémy n’est toujours pas convaincu, alors j’en remets une couche.

Pour commencer, parlons de l’usage de Scrum tel qu’il est recommandé. Rémy nous dit, à propos du relevé des heures passées sur les tâches :

J’ai vu cela dans plusieurs backlogs (dont une formation par une personne de Valtech qui est Scrum Master dans plusieurs projets importants) et dans certains outils. Ce n’est sans doute pas pour rien.

Ma réponse est qu’il faut se méfier des experts comme des vendeurs d’outil. Concernant Valtech, il arrive que des experts soient en désaccord[1] et j’ai le soutien, sur ce sujet, du plus grand d’entre eux. Que des outils agiles proposent de relever les heures des tâches ne me surprend pas, puisque que c’est même possible avec IceScrum[2]. C’est opportuniste.

La doxa est claire sur ce point : le relevé du temps passé sur les tâches d’un sprint n’est pas du ressort de Scrum. Mais est-ce que Scrum a raison pour autant ? Rémy nous cite des avantages, de son point de vue, de se préoccuper quand même du temps passé :

Entre autres pour améliorer mes estimations, pour prendre des décisions sur le fait qu’on a passé pas mal de temps sur une tâche et que le reste à faire n’a pas vraiment évolué (il y a un problème technique ou de compétence qu’on avait pas identifié), pour savoir où on en est (les deux informations, le reste à faire et le temps passé, m’ont été utiles)…

Je ne connais pas Rémy et je ne sais pas quel est son rôle, mais j’ai l’impression de retrouver à travers ses réactions un comportement que j’ai déjà rencontré sur des projets : celui d’un chef de projet qui n’a pas fini sa transition en ScrumMaster et qui fait encore du micro-management en consultant sa feuille de calcul remplie de chiffres, essayant d’y découvrir des problèmes. Ce n’est pas comme ça que ça passe avec Scrum :

  • les estimations sont collectives et pas faites par une seule personne
  • la découverte des problèmes se fait essentiellement lors des scrum meetings en discutant ensemble, et en particulier avec la 3ème question
  • le suivi des tâches du sprint est visible sur un tableau mural

C’est de voir les équipes appliquer ces pratiques de Scrum sur le terrain qui me fait dire qu’y ajouter le relevé des heures passées serait du temps perdu. Je vais même aller plus loin : je pense que, pour des sprints de 2 semaines voire 3, l’estimation en heures du reste à faire n’est pas très utile et qu’on peut s’en passer, ainsi que du burndown chart de sprint, à condition de faire un bon suivi sur le tableau des tâches.

Voir aussi sur le sujet :

Notes

[1] comme dans les commentaires suite à mon billet généralisation/spécialisation des rôles

[2] bien que je m’y sois toujours opposé

Voir aussi