Au cas où l’exemple de la liste de course de la semaine dernière n’ait pas fait mouche, l’analogie du GPS peut être utile pour convaincre product owner ou parties prenantes (du marketing au PDG) du fonctionnement adéquat de l’estimation ou de sa valeur.
C’est parti !
Siri, je veux aller chez le coiffeur
Lorsque vous interrogez votre GPS, vous lui indiquez une destination et vous lui faites confiance pour vous y mener.
⏳ À ce moment-là, votre GPS vous indique un temps estimé pour arriver à votre destination.
Certains GPS sont plus « perfectionnés » que d’autres, ils se fient aux données historiques des zones traversées pour affiner leurs estimations. Waze utilise même des données en temps réel pour adapter votre chemin par rapport aux embouteillages, travaux, etc.
Imaginons que le GPS soit votre équipe.
Le délai s’allonge …
Comment réagissez-vous si votre GPS vous annonce que, finalement, votre heure d’arrivée n’est plus 8h, mais 8h30 ?
- vous lui dites que c’est inadmissible ?
- vous lui dites qu’il s’est engagé à vous mener à votre destination à 8h et qu’il doit faire en sorte de tenir son engagement (quitte à vous tuer en ne tenant pas compte des limitations de vitesse ou en prenant le périph’ en sens inverse) ?
- vous lui demandez de vous mentir et de ne changer l’heure d’arrivée qu’à 7h59 ?
- vous prenez ce changement en compte et confirmez à votre rendez-vous votre arrivée à 8h quand même en mentant ?
- vous écoutez les raisons, vous avez confiance en votre GPS et vous annoncez à votre coiffeur que vous aurez du retard ?
Votre choix sera lourd de conséquences pour votre produit mais aussi pour la confiance que vous portent les équipes et les utilisateurs de votre produit.
Je lance le GPS mais je ne l’écoute pas
Lorsque vous lancez votre GPS, il vous propose un ou plusieurs itinéraires en vous expliquant les bénéfices ou inconvénients de chacun. Par exemple, c’est plus long de ne pas prendre la route avec péage ou même l’autoroute, mais cela peut être votre volonté afin de profiter du paysage.
🗺️ Vous lui indiquez alors clairement cette volonté et vous aurez un plan en accord.
Au milieu du chemin, vous voilà arrivé à un croisement où vous le GPS vous indique de tourner à gauche, sauf que vous décidez arbitrairement de prendre à droite, car la route semble meilleure par la droite par exemple, ou bien, ça “à l’air plus logique” pour vous.
🔀 Comment réagit votre GPS ? Il va vous donner une estimation du nouveau temps de parcours restant.
Quelle va être votre réaction ? Jamais vous ne lui demanderiez d’arriver à l’heure prévue à l’origine malgré ce changement ? Nooooooooon ! Alors pourquoi le faire avec des équipes de développement ?
🤔
Changement de destination !
Votre besoin a changé ! Avant le coiffeur, vous voulez maintenant passer au supermarché (super lien avec l’article précédent ➡️ Estimons l’estimation part 1 : La liste de course). L’équipe étant agile elle accueille ce changement avec plaisir.
1/ Soit vous le saviez déjà, et alors vous avez laissé votre GPS (l’équipe) établir un plan qui ne comprenait pas toutes les données, lui faisant perdre son temps ;
2/ Soit votre besoin a émergé pendant le trajet.
Vous entrez donc une nouvelle destination dans votre GPS qui vous trace alors un nouveau plan de route. Ce qui est sûr, c’est que vous ne pouvez pas lui demander d’arriver à la destination finale à la même heure, puisque vous imposez un détour (en plus du temps d’effectuer les courses).
Retour d’expérience
J’ai déjà participé à un PI planning (merci SAFe ! 😠) dans lequel, après une journée complète de planning pour les 4 prochains mois par les équipes (merci le cycle en V 😠), le chef de projet estime et décide que telle équipe peut prendre un sujet de plus et donc, qu’elle doit le prendre.
Dans la salle, ce fut le malaise. Le message passé pouvait être compris comme, au choix :
- vous ne savez pas de quoi vous parlez, moi je sais mieux
- vous n’avez pas voulu prendre un sujet (sous entendu par fainéantise ?)
- j’avais de toute façon déjà prévu le plan et votre journée de planification n’a servi à rien
- vous devez vous engager sur ce en quoi vous ne croyez pas
Ce fut, bien sûr, désastreux #CargoCult.
Conclusion
Comme nous l’avons vu dans ces deux articles, les estimations ne doivent être utilisées qu’à titre d’information pour l’équipe. Un mot à proscrire est “engagement”, en rappelant que justement ce terme a été retiré du Scrum Guide en 2011, tellement il a été mal interprété.
Engagement a été remplacé par “prévision”. La prévision peut évoluer au fur et à mesure que l’équipe acquiert de nouvelles connaissances.
L’estimation d’une équipe n’est valable qu’au moment où elle est faite, d’après les informations connues de l’équipe à ce même moment. Une estimation devient obsolète juste après avoir été donnée. (#estimationQuantique)
Vouloir qu’une équipe se conforme à une estimation bêtement, c’est mettre en cause la viabilité du produit tout entier.
➡️ N’hésitez pas à partager votre façon de voir les estimations et votre façon de convaincre de votre point de vue.