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é

Commentaires

1. Le jeudi 12 juin 2008, 17:28 par Alexandre Boutin

Claude, encore un effort pour aller plus loin, et voici la nouvelle méthode XS bientôt disponible ("eXtreme Scrum") :)

2. Le vendredi 13 juin 2008, 15:38 par Camille Bloch

C'est vrai que c'est dure de passer de "je compte combien de temps je passe" à "je compte combien de temps il me reste".
Chez nous, lors des daily scrum, il n'est pas rare de voir ce vieux réflex revenir.
Cependant, ces heures ne sont pas relevées, et on corrige le tir dès que possible.

Pour réagir aux arguments de Rémy, le fait de vouloir expliquer pourquoi on a pas tenu les délais est en effet un besoin dans les entreprises, pour faire du reporting, mais à mon sens (et c'est ce que nous faisons), le burndown chart doit permettre de visualiser les inflexions de la courbe et de voir ce qui s'est passé à ce moment là.

Comme pour les estimation, c'est une analyse collective du problème qui doit prédominer et le temps passé n'a plus de raison d'être, c'est l'analyse en profondeur qui ressortira.

Mais c'est vrai que le sujet peut faire débat longtemps.

3. Le lundi 16 juin 2008, 11:03 par Eric

Claude,

Je suis d'accord avec tous tes posts sur le sujet, mais puisqu'on parle de Valtech, j'interviens... ;-)
Je pense que Rémy a dû assister à un cours de David plutôt que moi, mais les supports sont communs, ainsi que notre discours.
Quand je présente ce slide, j'explique bien que la colonne 'actuals' (temps vraiment passé) est une possibilité. C'est utile sur certains projets, d'autres non (et j'enlève la colonne dans ce cas).

Dans mon expérience, les cas où nous avons tenté de tracer le temps vraiment passé n'ont pas été concluants. Soit les valeurs étaient arbitraires ("j'étais toute la journée au bureau hier, donc 2h sur la tâche 1, 4h sur la dernière... et on remet 1h sur chacune pour atteindre 8 heures"), soit peu fiables (total d'heures inférieur à 8h par jour). Et le pire, c'est que ça nous servait peu. Impossible pendant le Sprint Planning de se reporter au temps prévu dans le backlog précédent: il n'y a pas assez de temps, et il est difficile de dire si des tâches aussi micros (~1 jour) sont réellement les mêmes.

Il m'est aussi arrivé d'entendre dire dans des situations du type blaming: "ah, si tu avais tracé le temps passé, on pourrait se défendre". Inutile d'insister sur mon avis sur la question... ;-) En tout cas, il a été suffisant dans ces cas (exceptionnels) de réunir l'équipe pour leur demander combien de temps à été vraiment passé.

Pour conclure, YMMV (votre expérience peut varier) et il est toujours possible de rajouter la colonne du temps passé d'une itération à l'autre. Faire des essais suivie d'une rétrospective est la seule bonne façon de savoir si c'est une bonne idée...

4. Le mardi 17 juin 2008, 19:07 par Laurent

Ok pour ne pas suivre le consommé sur les tâches.
Mais alors, comment calibrer l' IEH?
L'itération backlog étant construit à partir de la vélocité et de cette notion d'Ideal Engineering Hours. Comment vérifier que l’on est à 5 ou 6 ou 8 IEH, si l’on ne fait pas le rapport entre l’estimé d’origine et le consommé final.
Je suis bien sur d’accord avec tous les posts sur le retour d’expérience, montrant que l’ « actual » est peu fiable et donc non utilisable.
Mais si l’on montre que c’est dans l’intérêt des membres de l’équipe de calibrer leur vélocité avec une charge de travail soutenable pour tous, c’est un des objectifs de Scrum aussi.
Une équipe qui tient ses engagements de vélocité en travaillant 14 heures par jour ne va pas les tenir longtemps.

Bonne escapade montpelliéraine!