« On arrive bientôt ? » ou la maitrise du temps et agilité

Préambule : Ce post est la traduction d’un autre post d'Aaron Bjork Principal PM chez Microsoft.
Merci à Visual Studio Magazine et Aaron de m'avoir autorisé à traduire et publier cet article

Article original : Remaining Work is Key for Agile



Aaron Bjork nous explique pourquoi le travail restant à faire est la mesure la plus importante sur nos projets agiles.

L'été dernier, avec ma famille, sur la route des monts Cascade, dans l'État de Washington, nous avions six heures de route devant nous.
Pour ceux d'entre vous qui ont une famille, vous savez que six heures, c'est long en voiture, notamment avec des enfants âgés de 6, 7 et 9. Nous étions sur la route depuis environ 30 minutes quand ma fille de 6 ans, Lily, me pose la question, que tous les parents ne connaissent que trop bien : « on arrive bientôt ? »

Calmement, Je lui réponds  «Non, nous n’y sommes pas encore », Lily me rétorque  «Combien de temps encore ?"
Cette conversation, je suis sûr que tous les  parents l’ont eu.

Après ce voyage, j'ai réfléchi sur l'interaction avec ma fille et j’ai réalisé qu’il y avait un vrai parallèle avec le suivi des projets logiciels. Ma réponse à Lily était assez simple. Quand elle a demandée combien de route il restait, je lui ai donné ma meilleure estimation de la quantité en temps de route restant : cinq heures.

Sans surprise, elle n'était pas particulièrement heureuses de cette réponse, cinq heures, c’est un temps long quand on a 6 ans.
Dans le même temps, la réponse était satisfaisante car elle définissait correctement ce qui nous attendait. Elle peut ne pas aimer le fait que nous avons encore cinq heures de route, mais au moins elle est informée et peut anticiper le reste de l'après-midi.

A partir de là, notre conversation aurait été complètement différente si j'avais répondu par : «Nous voyageons depuis 30 minutes".

Elle m’aurait probablement regardé  d’un air curieux. Elle n'était pas particulièrement intéressée par la distance parcourue. Cela ne répond pas à sa question. Elle veut juste savoir quand nous arriverons à notre destination. Elle voulait savoir combien de temps encore elle devrait rester dans la voiture.

La réponse « 30 minutes de conduite » est de nature à souligner notre effort, mais ne lui donne aucune réel appréhension de « quand arriverons-nous ? », « en avons-nous encore pour 1 heure ? », « pour 10 heures ? »

Les équipes de développement ont ce genre de conversations lors de la discussion autour des tâches restant à faire et du travail que cela représente.

Je sais que l’estimation des temps fait partie du quotidien de des équipes de développement.

C'est même une partie importante et essentielle du processus.

L'estimation fournit un point de départ qui peut être utilisée pour commencer à avoir des indicateurs de progression. Sans l'estimation, l'équipe avance à l'aveuglette.

Toutefois, Je vois beaucoup d'équipes accorder trop d'importance estimations, tout en oubliant le point le plus important : le travail restant.
La plupart des équipes sont conditionnés à suivre trois indicateurs:

• Les estimations originales
• La somme des travaux réalisés
• La somme des travaux restant

Je crois qu'il y a une place pour chacun de ces trois points dans un projet, mais je dirais qu’un seul compte vraiment : le travail restant.

Pourquoi ? Le travail restant est le seul indicateur qui aide l'équipe à mesurer la distance qui les sépare de la ligne d’arrivée.

Les estimations

Démarrons avec le suivi des estimations. L'argument commun pour le suivi des estimations initiales, c'est qu'il permet à l'équipe au fil du temps à améliorer leur capacité à estimer.

Il est assez commun de vouloir revenir sur l’estimation des tâches et de les comparer avec le temps passé à réaliser ces tâches. Le problème avec cette approche est qu'elle met l'accent sur la précision de l'estimation, au lieu de se concentrer sur l'accomplissement de la tâche.

« Agile » nous dit que les choses vont changer en cours de développement. C'est une partie normale du processus. A cause de cela, les estimations ne devraient pas être parfaites.

Rappelez-vous: l'objectif est de terminer le projet et offrir de la valeur aux clients.

Le but n'est pas de produire des estimations parfaites. 

Je ne prétends pas rejeter les estimations ou de mal faire le travail d’estimation. Je dis plutôt qu'une fois une estimation créée, l'équipe devrait focaliser son attention sur le travail restant. L'estimation est juste le point de départ pour savoir combien de travail il reste.

Travail Terminé

La plupart des équipes réagissent mal la première fois qu'on leur demande de laisser tomber l'indicateur "travail achevé".

Ils l'ont suivi de près pendant des années et sont formatés pour y faire attention. En réalité, suivre le temps de travail terminé n’apporte rien à la réussite du projet. Qu’importe si l’équipe a terminé en 100 heures de travail, sur 150 heures nécessaires au respect de son engagement. Ce qui est important, ce sont les 50 heures restantes.

Se focaliser sur le travail accompli peut conduire à un jeu dangereux, où l'équipe commence à plus se concentrer sur ses efforts, plutôt que sur son résultat.

Encore une fois, je ne dis pas que suivre ce qui se fait n'est pas important. Les équipes doivent absolument suivre ce qu'ils ont fait et se réjouir de l'achèvement de chaque élément du Backlog.

Mais ne laissez pas ce suivi détourner l'équipe de son but.

Revenons à mon voyage en famille l'été dernier.

Finalement, il nous a fallu près de sept heures pour arriver à destination. Et quand nous sommes arrivés, nous étions tous ravis et prêts à profiter de nos vacances.
Personne ne se souciait plus que mon estimation de cinq heures était un peu sous-évaluée. Nous avions décidé, à mi trajet, de nous s'arrêter pour prendre un repas et aussi de voir quelques curiosités le long du chemin.

Après notre départ, Il y a eu des changements, et nous nous sommes adaptés à ces changements.

Nous étions arrivés, voilà ce qui était important.