Feuilles de temps: Bon ou mauvais en Agilité?

Publié par Louis-Philippe Carignan le mardi 28 mai 2013 à 17:00

Cette question m’est souvent posée depuis que j’œuvre dans le domaine des technologies de l’information. Depuis que j’agis en tant que coach Agile, j’ai un certain devoir d’éduquer mes clients à propos de la nécessité de poursuivre avec le suivi des feuilles de temps lorsque je mentionne que c’est le travail qui reste à faire qui est important et non le travail effectué jusqu’à maintenant.

Ayant moi-même été sur des projets où remplir ma feuille de temps était une perte de temps (sans jeu de mots), je peux comprendre les frustrations de certains développeurs qui désirent garder le focus sur le travail pour satisfaire le client. D’un autre côté, je comprends aussi le fournisseur de services qui doit facturer son client pour les heures passées sur son projet. Et pour pouvoir facturer correctement, le département de la facturation doit demander aux développeurs le temps passé sur le projet du dit client.

J’ai donc creusé le sujet pour connaître les opinions de certains experts reconnus dans le domaine des technologies de l’information. Voyons voir ce que ces experts ont à dire à ce sujet.

La version de Scrum Inc

D’un côté du terrain, nous avons Scrum Inc, piloté par Jeff Sutherland, qui semble contre l’idée de comptabiliser les heures dans une feuille de temps lorsqu’on fait partie d’une équipe Scrum.

Sur leur bogue, les gens de Scrum Inc. ont trois billets où un préjugé très défavorable envers les feuilles de temps est exprimé.

Ces billets, étant publié sur plusieurs années, nous permettent de conclure que c’est une opinion que Sutherland et son équipe tiennent depuis longtemps. À la lecture de ces billets, voyons voir comment Scrum Inc. apporte plusieurs de l'eau au moulin en défaveur pour la tenue des feuilles de temps en mode Agile.

Le gros bon sens selon Scrum Inc.

Tout d’abord, les arguments « gros bon sens » de Scrum Inc. contre les feuilles de temps sont tous à fait réalistes bien qu’aucune donnée vient supporter ces énoncés :

  • they demotivate developers
  • 10-15% loss of productivity is the minimum
  • developers have to fake the time to fill them out properly
  • erroneous data is used for reporting and management makes bad decisions
  • customers are deceived
  • they have nothing to do with quality code production
  • they focus the whole organization on phony data instead of production

Si vous avez déjà été membre d'une équipe Agile où il était requis de remplir votre feuille de temps, vous partagez probablement l’un (ou plusieurs) de ces énoncés. Et pourtant, comme le dit si bien Scrum Inc. certaines entreprises semblent être déterminer à remplir les feuilles de temps même si cela n’apporte aucune valeur à l’organisation.

there is a psychological dependency so strong, it is as if they are on drugs.

Une façon « Lean » de rapporter le temps restant

Lors de son passage chez PatientKeeper en tant que CIO, Jeff Sutherland a mené un sondage auprès de ses équipes Scrum pour identifier la meilleure façon de remplir les feuilles de temps. Les réponses ont été contre-intuitive où l’équipe ne voulait même pas afficher explicitement le temps restant sur chaque tâche, ce qui est habituellement encouragé en Scrum. Cela les dérangeait de leur véritable travail à faire et leur estimé restait assez variable à cause du problème à résoudre. Ils sont donc arrivés à cette façon de faire très « Lean ». 

Time remaining to Sprint completion is all that is reported publicly and the team remains focused on what it takes to get "Done" at the end of the Sprint and does not even feel the questions asked relate to time reporting in any way.

L’équipe voulait donc la confiance des gestionnaires en échange de cette façon simpliste de rapporter les heures restantes. On utilisait le temps restant de l’itération pour informer les parties prenantes et l’équipe n’était pas perturbée par aucune donnée liée à propos du temps. Elle pouvait donc se concentrer à livrer de la valeur.

Livrer de la valeur

L’un des points majeurs de l’Agilité est de livrer de la valeur à son client. Contrairement à un gestion de projet traditionnelle où l’on essaie de respecter les trois pointes du triangle de fer (temps, budget, fonctionnalités), on cherche à maximiser la valeur d’affaires livrée au client lorsqu’on fonctionne en mode Agile. On encourage les équipes Agile à penser en terme de valeur d’affaires ainsi que le retour sur l’investissement que bénéficiera la clientèle en utilisant le logiciel. Regardons de plus prêt comment ce principe est employé dans les billets de Scrum Inc. lors de leur réflexion à propos de l’utilité des feuilles de temps:

One difficulty when estimating in hours is that time measures input, and Scrum is concerned about output.

Un peu plus loin dans ce même billet, on mentionne un exemple où une firme d’avocats a surfacturé un client pour une simple question de rentabilité.

If the lawyers had instead focused on the quality of their work (the output in this case) and not billable hours, the client, rather than suing them, would have gladly paid the bill.

On sent vraiment l’influence de livrer de la valeur lorsque l’auteur affirme à la fin de ce billet que : 

Business probably won’t improve until they start to focus on quality of outcome rather than quantity of input.

Pour Scrum Inc., j’en conclu que la nécessité de comptabiliser les heures travaillées est un dérangement dans la livraison de valeur pour le client. J'en déduis qu'il faut garder les équipes concentrées sur l’objectif d’affaires et les feuilles de temps n’ont pas leur place dans cet objectif.

La version de Joel Spolsky

De l’autre côté du terrain, Joel Spolsky a une toute autre vision face à la feuille de temps. Dans son billet Evidence Based Scheduling, Spolsky présente une technique mathématique pour prédire une date de livraison en se basant sur l’historique des tâches faites par l’équipe lors d’autres projets.

Spolsky propose de garder un historique des temps estimés et actuels passé sur chaque tâche. Avec le temps, le développeur pourra s’améliorer en regardant où sont les plus grands écarts entre ces deux valeurs. Il suggère l’emploi d’une machine de Monte Carlo pour générer des probabilités quant à la livraison d’une version. Il suggère aussi l’utilisation d'un logiciel que sa compagnie vend.

Sans aller dans les détails de la technique qui est quand même compliquée, on peut voir à la lecture de ce billet que Spolsky favorise les feuilles de temps pour permettre aux développeurs de s'améliorer.

Dans ce billet, je suis d’ailleurs surpris par le concept de vélocité proposé par l'auteur. Pour Spolsky, la vélocité est la division du temps estimé sur le temps actuellement passé sur cette tâche. Premièrement, une vélocité est basée sur une unité de temps (m/s, km/h, points/itération). En divisant du temps (estimé) par du temps (actuel), on se retrouve avec un ratio sans aucune unité. Je doute fortement de l’effort de réflexion que Spolsky a effectué pour arriver à ce concept.

Et bizarrement, Joel Spolsky partage la même prémisse que Scrum Inc. quant à livrer de la valeur.

You want to be spending your time on things that get the most bang for the buck.

Cependant, son approche est différente puisque pour lui, 

Realistic schedules are the key to creating good software.

On peut donc voir une approche ortogonale à celle de Scrum Inc. et pourtant, elle semble répondre au besoin de livrer de la valeur d'affaires au client.

La version de Jurgen Appelo

L’auteur du livre Management 3.0 et auteur du blogue noop.nl a déjà écrit un billet où il se prononce sur le sujet. En quelques lignes, Appelo se situe entre Scrum Inc. et Spolsky.

Il mitige la position de Scrum Inc. puisque selon lui, il est important de mesurer la profitabilité d’un projet et les feuilles de temps permettent de déterminer cette mesure. De l’autre côté, il est contre l’idée de Spolsky de suivre chaque tâche dans un projet puisque le client n’y gagne aucune valeur et qu’habituellement, ces projets sont à coût fixe.

Il en arrive donc à la conclusion qu’il se situe entre Scrum Inc. et Spolsky : 

  • So yes, you must track time in order to track project profitability.
  • And no, you should not track time in order to improve task estimability.

La version Louis-Philippe

Mon opinion est relativement semblable à celle de Jurgen Appelo. Dans mon jeune temps, je penchais du côté de Scrum Inc. mais avec l’expérience où certaines particularités m’ont fait grandir, j’emprunte certains arguments de Jurgen (mais aucun de Spolsky).

Pour ma part, je commencerais par identifier les personnes qui vont consommer les feuilles de temps.  Par exemple, si le responsable de la paie est la seule personne qui consomme les feuilles de temps produites par les équipes Scrum, je demanderais aux équipes de rentrer deux lignes dans leur feuille de temps : 

  • Heures passés au bureau
  • Heures où vous étiez absent du bureau

Par exemple, pour que la comptabilité effectue les bonnes paies à la fin du mois, je demanderais aux équipes de rentrer leurs absences dans la feuille de temps. Cela aiderait la comptabilité à générer les paies exactes et éviter des corrections à chaque mois. Si le reste du temps est passé sur un projet de recherche et développement, je simplifierais à sa plus simple expression les heures passés au bureau pour ne pas déranger l’équipe.

Je rejoins aussi Jurgen Appelo à propos de comptabiliser les heures pour la facturation. Je comprends le point de vue de Scrum Inc. à propos de livrer de la valeur affaires pour son client et « l’interférence » causée par l’inscription des heures sur la feuille de temps. En tant que développeur dans une équipe, j’ai un « autre » client, c’est-à-dire l’organisation qui paie mon salaire pour exécuter les services à mon vrai client. Pour me payer, l’organisation pour laquelle je travaille doit facturer un client avec qui elle est liée contractuellement. Je comprends qu’il peut y avoir de l’abus dans certains cas comme le remarque Scrum Inc. où l’important devient simplement de facturer des heures imaginaires. Je préfère donc faire abstraction de cette idée peu probable et emprunter l’argument de Jurgen.

Cependant, et bien que Joel Spolsky a eu du succès avec sa technique ainsi que les projets qu’il a lancé (StackExchange, Trello), je ne vois pas l’intérêt de compiler l’historique des tâches pour chaque développeur dans l’objectif d’apporter une meilleure prévisibilité. Étant un adepte des systèmes complexes adaptatifs où un projet logiciel est complexe et impossible à prévoir d’un bout à l’autre, je préconiserais une approche où l’on fait des temps d’arrêts fréquents pour regarder où nous sommes rendus et ajuster le tir. L’approche de Spolsky semble viser un certain déterminisme que je réfute lorsqu’on parle de développement logiciel.

blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.