La malédiction du jour homme

Are You Agile ? sam. 24 mars 2012

Malédiction

Question récurrente parmis mes interventions : mais bon sang pourquoi ne pas associer, rapprocher, remplacer les points user story par des jours hommes ? Sous-entendu parfois clairement exprimé : c’est juste "votre" mysticisme agile à la noix, mais cela n’a aucune incidence en réalité, encore un gadget marketing ces points user story.

Non. il est très important -à mes yeux- de ne pas faire de parallèle entre les points user story et des jours hommes.

Pourquoi ?

La gestion des jours hommes est une vieille pratique obsolète mais profondement ancrée dans notre culture qui nous renvoie directement au projet au forfait et à son mensonge historique : il serait possible de respecter une promesse à triple visage qui consiste en un engagement simultané sur la date, le scope, le coût. (Pour l’agile c’est un mensonge notoire). Sur le terrain j’observe que dès que l’on parle de jours hommes cela implique de facto tout un ensemble d’autres informations particulièrement nuisibles : une cristallisation autour de cette hydre (scope,coût,date).

Imaginons 2 cas de figures concernant un manager bien intentionné qui décide de compter en jours hommes :

Cas de figure 1

Il observe les précédents sprints et en déduit une équivalence entre les points user story et les jours hommes. Or lors du sprint suivant l’équipe s’engage d’après ses calculs sur 40 jours hommes alors que si il observe le temps de présence de l’équipe (sprint de 2 semaines, 6 personnes, soit ~60 jours), celle-ci pourrait s’engager sur bien plus. Que va faire le manager bien intentionné. A minima il va s’en émouvoir. Et comme c’est un manager son émotion a de l’influence, cela risque d’entre être fini des prérogatives de l’équipe qui aura beaucoup de mal a justifiée de ne pas s’engager "à la bonne hauteur". Et c’est en fini de l’agilité. Fini. Basta. On est retombé dans un système de "command & control" autant obsolète que néfaste.

Cas de figure 2

Un manager bien intentionné demande à son équipe de chiffrer en jours hommes directement plutôt que d’utiliser les points user story. Là, le message est immédiat. Comment dire à son manager que l’on souhaite s’engager sur 40 jours hommes alors que l’équipe a la capacité d’en réaliser 60 ? La sortie de route est rapide : soit l’équipe va gonfler ses estimations pour faire coïncider la capacité de l’équipe et engagement. Soit elle va effectivement s’engager sur 60 jours au détriment de la qualité de réalisation. On retombe dans le mensonge de l’engagement au forfait : sauvons les apparences ! en fait l’objectif de l’équipe a implicitement changé : il ne s’agit plus de s’interroger sur la véritable estimation des éléments, sur sa véritable capacité, mais de réussir à faire coincider deux valeurs (quelque soit le fond). On a perdu le fond pour la forme. Finie l’agilité.

Dans les deux cas l’introduction des jours hommes a rendu les estimations caduques. Dans les deux cas on est revenu à une relation de "command & control" néfaste au projet.

C’est aussi pour cette raison que je déconseille vivement l’utilisation des "jours ideaux".

Pourquoi les estimations de l’équipe diffèrent-elles de sa capacité de réalisation ?

Car il est très difficile d’estimer en jours hommes, voire impossible. Il y a trop de critères, donc trop de complexité, donc trop peu de prédictibilité pour que ces calculs soient bons. Dans la réalité les gens qui réussissent à estimer en jours hommes ne se basent pas sur un calcul mais ils reproduisent et s’inspirent de leurs expériences passées, c’est agile : il reproduise une cadence qu’ils ont observés dans un contexte similaire. La difficulté étant justement de retrouver un "contexte similaire", il y en a peu. très peu. très très peu. Par contre des réalisations dans un projet : il y en a beaucoup et elles sont présentes dans notre esprit car récentes. L’estimation agile se base donc beaucoup sur une comparaison des différents éléments du projet. Cet élément est-il plus dur, complexe, long à faire que celui-ci ? La comparaison, et la triangulation (3 éléments) est la base de l’estimation agile. Si j’introduis la notion de "jour homme" la comparaison est comme empoisonnée. On a fait entrer un élément parasite qui rappelle de nombreuses autres contraintes. Le "jour homme" a une capacité d’attraction fatale assez phénoménale. Prononcer le mot "jour" ou "heure", et la personne s’enferme d’elle même dans un piège dont elle sort rarement gagnante.

L’engagement est différent de l’estimation !

Je demande aux équipes agiles d’occulter les points user story lors de leur engagement. Il faut qu’elles se basent sur leur ressenti : celui-ci a de la valeur car les équipes viennent de réaliser plusieurs itérations à la durée strictement identique. Comme ci-dessus : on compare. Et on compare ce qui est comparable : les itérations entre elles, ou les user stories entre elles, mais pas une itération à une user story, et donc l’engagement du sprint est une expérience différente que la simple somme de points user story. (La vélocité peut servir d’indicateurs mais n’intervient pas dans l’engagement).

A quoi peuvent servir les jours hommes ?

Malédiction

Dans les deux cas évoqués plus haut (notamment le premier) vous pouvez me répondre : ce manager bien intentionné peut aussi ne faire subir aucune pression à l’équipe même si il décide de compter dans son coin en jours hommes et garder cette information pour lui ? Pour moi ce cas de figure est extrêment rare : pourquoi compter en jours hommes ET garder l’information pour soi ? A quoi cela servirait-il ? Et du moment qu’il évoque les jours hommes il risque de rendre caduque les engagements et les estimations. Donc autant ne PAS le faire.

En fait ce monsieur cherche a projeter une planification, un planning release, savoir a priori quel sera le scope cible pour telle date afin de lui permettre de faire des arbitrages. C’est la bonne raison (c’est notamment le désir du product owner) : est-ce que nous sommes dans les clous ? est-ce que nous sommes dans le budget ? Est-ce que nous pouvons envisager sortir ce scope à cette date ? Quel scope pouvons nous sortir à cette date compte tenu de notre capacité ? L’agile dit : voici une projection, cette projection est d’autant plus fiable qu’elle se base sur la cadence que nous avons observé sur le terrain, mais cela demeure une projection. Cette cadence est observée en user story ou en autre chose (potentiellement simplement en user story). Mais surtout pas en jours hommes pour les raisons évoquées plus haut.

On ne calcul pas un budget avec la suite de Fibonacci monsieur !

Je me suis entendu dire l’année dernière : "On ne calcul pas un budget avec la suite de Fibonacci monsieur !"

C’est vrai. C’était rigolo comme réplique, mais fondé. Vous voulez savoir combien vous devez engager, ou combien vous avez engagé, c’est normal. Rien ne vous empêche de compter VOUS en jours hommes. Mais il ne s’agit pas d’estimation et d’engagement : ça c’est le rôle de l’équipe ou des équipes. Vous pouvez par exemple estimer que si on place 2 équipes de 6 personnes pendant 1 an sur un projet celui va "coûter" ~2500 jours hommes (216*12, 216 étant de mémoire le nb de jours ouvrés moins les 5 semaines de vacances d’une année). On peut ainsi se projeter en jours hommes ou faire des bilans mais comme vous l’aurez compris on comptabilise un engagement de moyens : combien de personnes, combien de temps ? et pas un engagement forfaitaire : combien de personnes, combien de temps … et quel scope. Et la personne qui s’autorise à compter en jours hommes pour "budgetiser" ne fait pas parti de l’équipe, sinon de nouveau comme évoqué plus haut elle va rendre caduque les estimations.

Le point de user story peut muter, le jour homme est immuable.

Autre effet pervers : le point de user story peut évoluer au fil du temps. L’équipe s’améliore, elle connait de mieux en mieux son périmètre et donc ses contraintes et ses facilités, son estimation va donc naturellement évoluer. Hypothèses : ce qui était facile au début du projet on sait désormais que c’est dur car on a découvert les anguilles qui se cachaient sous les roches, à l’inverse ce qui était dur au début du projet est peut-être désormais grandement facilité (par exemple par tout le code qui a été généré, par la connaissance que l’on a désormais des problématiques, etc.). A quel moment les personnes qui souhaitent faire un lien entre les points user story et les jours hommes adaptent-elles leur taux de change ? rarement ? c’est donc que le jour homme n’a pas la bonne valeur. Souvent ? mais donc si la valeur du jour homme change constamment…

Pour finir,

Vous pouvez déterminer le nombre de lignes de code générées par l’itération. En associant un taux de lignes de code par jour vous devriez pouvoir en déduire la marge générée par le lot 1 de votre contrat si il ne s’agit pas d’un appel d’offre publique et si vous ne faites pas de offshore. Sinon vous devez multiplier le tout par 2,75. Pour cette dernière recommandation, bon courage (et naturellement c’est une plaisanterie… dire que je me sens obligé de préciser…)

Fuyez le jour homme avant qu’il ne vous dévore.

Concernant les estimations elles-mêmes je vous renvoie à mon feedback sur Agile Open Sud 2012.

Publications & Supports

Quelques écrits un peu plus pérennes que les autres.

La horde agile

Qu’est ce qui fait de l’homme, l’homme ? Observons nos ancêtres qui parcouraient la Savane. Nous n’avions ni dents acérées, ni muscles proéminents, encore moins une rugueuse carapace. Et pourtant nous avons émergé et finalement dominé le monde. Pourquoi ? parce que nous avions cette culture de l’adaptation en milieu complexe. Avec Descartes et les Lumières nous avons un peu oublié cela. Nous avons une réponse cartésienne à chaque question. Et nous pensons que le monde marche ainsi. Mais ce n’est plus le cas : interdépendance, connectivité totale, immédiateté, simultanéité, globalisation, le monde est de nouveau imprédictible. Aujourd’hui que peut nous enseigner notre vieille horde ?

La horde agile, PDF
La horde agile, Epub (ebook)

Supports des séminaires & conférences

Chez Speakerdeck pour les slides ; et Vimeo pour les vidéos.

Le grenier à outils

C’est dans le grenier que je stock les éléments persitants ou récurrents comme par exemple : Peetic (un scénario qui permet d’outiller mes formations), le scrumshot pour évoquer scrum, ou "la scierie des pratiques", (un jeu pour discuter sur nos pratiques), des supports et slides de formations, etc.

La crypte

Je range dans la crypte des vieilles choses qui n’ont pas de liens avec le blog si ce n’est que c’est moi qui les ai réalisées. Elles ne sont pas non plus liées à l’agilité, quoique…

Missions & Formations

Je vous accompagne en mission 75% du temps, et en séminaires ou formations 25% du temps.
Les Formations les plus courantes se trouvent ici, mais vous pouvez demander du à façon en utilisant
le formulaire de contact.

Une mission typique sur 6 mois demande 15 jours en général (je suis contre l'accompagnement à plein temps qui freine la conduite du changement), mais vraiment... cela dépend du contexte.

Mon périmètre
Management organisationnel, conduite du changement, agilité.

A propos

Blog maintenu par Pablo Pernot @pablopernot de smartview.
Agent provocateur (de changements ? d'idées ? d'émotions ? )
Paris & Montpellier & TGV.
Après une maitrise sur les Monty Python, un DEA sur le non-sens et l’absurde, l’entame d’un doctorat sur les comiques cinématographiques il parait normal que je me sois lancé dans le management et la conduite du changement, c’est -finalement- une suite logique.

Actuellement un coach expérimenté en management organisationnel, conduite du changement, et agilité.
Fondateur de SmartView.

Pour mieux me connaitre, jetez un dé à six faces, et piochez la citation :

  1. Aucun plan ne survit au premier contact avec l’ennemi —Von Moltke
  2. Je refuse de faire partie d’un club qui m’accepterait comme membre ! —Groucho Marx
  3. L’enthousiasme fait les compétences —auteur inconnu
  4. On a deux vies, la deuxième commence quand on découvre que l’on en a qu’une seule —Confucius
  5. Ils ne savaient pas que c’était impossible, alors ils l’ont fait —Mark Twain.
  6. Trop de sages femmes, le bébé est mort —proverbe roumain

Archives

2014 | 2013 | 2012 | 2011 | 2010 | 2009