Je suis de retour avec mes questions/réflexions bêtes.
J’ai revu un cours vidéo sur Scrum où le formateur indiquait que Scrum était basé sur l’empirisme ce qui veut dire qu’« on va utiliser la connaissance, l’expérience et [qu’]on va prendre des décisions sur ce qui est connu ». Autrement dit, ajoute-t-il « on va pas faire des projections à n’en plus finir, on va pas faire des hypothèses à n’en plus finir ».
J’entends tout ça.
Cependant, ça a fait tilt car, selon moi, c’est antinomique avec les estimations qu’on demande de faire aux développeurs lors du sprint planning.
En effet, si Scrum est basé sur l’empirisme, sur le fait qu’« on ne va pas faire des projections à n’en plus finir » pourquoi demande-t-on aux développeurs de faire, en quelque sorte, le contraire, de se projeter quand on leur demande de faire des estimations pendant le sprint planning ?
Dit autrement, pourquoi fait-on des estimations alors que l’empirisme, c’est utiliser la connaissance, l’expérience et prendre des décisions sur ce qui est connu ?
A moins d’avoir des dons de voyance (et encore), par définition 1) on ne connait pas l’avenir et 2) on n’en a pas fait l’expérience, puisque ça n’est pas encore arrivé.
Dans ce cas-là, pourquoi continue-t-on de demander aux développeurs de faire des estimations, dans le cadre de scrum (notamment du sprint planning) tout en sachant pertinemment qu’il va y avoir un delta, plus ou moins grand, entre les estimations et la réalité ?
Qu’en pensez-vous, vous qui avez (bien) plus d’expérience que moi dans Scrum ?
Il n’y a pas de réflexion ou de question bête, uniquement parfois des questions non posées. Voilà pour la philosophie de comptoir.
En fait, on ne leur demande pas et ce n’est pas de la voyance que de leur demander (oui, ça aussi, c’est un peu paradoxal).
Ce n’est pas de la voyance parce que l’échelle de temps (le sprint) reste appréciable par une équipe. C’est le seul engagement porté par l’équipe de développement, et elle ne porte même pas sur le fait qu’ils vont réaliser un certain nombre de points, mais uniquement sur le fait qu’ils atteignent un objectif de sprint. Autrement dit, c’est à l’échelle d’une équipe (donc assez réaliste) et ce n’est pas obligatoire.
Et on ne leur demande pas parce que les estimations ne sont pas une fin en soi, elles ne sont qu’un moyen pour aider l’équipe de développement à prendre un engagement, celui d’atteindre un objectif de sprint.
Donc on peut s’en passer, si l’équipe de développement est capable de s’engager sans ça (maturité), ou si elle est réellement autonome et responsable dans ses choix (comment fait elle sans estimation pour choisir entre 2 options techniques possibles ?), ou si le PO est 100% certain de ce que lui donne l’équipe de devs (Comment le PO fait il pour construire une roadmap, aussi courte ou longue soit elle, sans un minimum de visibilité de l’équipe de devs ?), voire si l’organisation est suffisamment mûre pour se dire que piloter un projet simplement par le respect d’un engagement n’est plus une option (mais c’est un autre sujet). Ça fait quand même beaucoup de si. Il est donc généralement préférable que l’équipe de devs dispose et utilise un système d’estimation qui lui convient, parce que ça aide l’organisation à être efficace et à prendre les bonnes décisions.
Comme dit plus haut, tout d’abord on parle d’estimations à court terme quand l’équipe prépare son plan de sprint en Sprint Planning.
Corolaire : plus la durée de sprint est longue, plus l’exercice de planification va ressembler à un travail de funambule.
Ensuite, l’engagement de l’équipe n’est pas sur ce plan (le Sprint Backlog) mais sur le Sprint Goal. Et un bon Sprint Goal serait négociable, sera orienté impact, de sorte que l’on pourra faire face aux imprévus en cours de Sprint – tirer parti de l’empirisme donc.
De même une bonne pratique en Sprint Planning est de plutôt sous-charger l’équipe, du moins vis-à-vis des éléments qui servent à atteindre le Sprint Goal. C’est un pattern organisationnel : une équipe qui atteint tôt son Sprint Goal va s’améliorer plus vite.
Une autre pratique, en lien direct avec l’empirisme, est de ne pas planifier l’ensemble du Sprint en Sprint Planning mais seulement les premiers jours, seulement faire en sorte de pouvoir « se lancer » dans le Sprint, et d’ensuite faire de la planification en continu, au fil de l’eau et à partir de ce que l’on apprend et découvre.
Tous ces éléments et approches permettent à une équipe de faire une planification qui n’est pas antinomique avec l’empirisme.
A contrario, cette planification permet de tirer parti de l’empirisme : si on ne se fixe pas d’objectif, d’hypothèse à valider ou invalider, alors impossible une fois arrivé au bout de la boîte de temps de voir si l’on a appris quelque chose et quoi.
La planification en Sprint Planning permet d’inspecter la progression vers le Product Goal en Sprint Review (via le Sprint Goal), elle permet aussi une adaptation au quotidien (notamment en Daily Scrum, mais pas que) en inspectant le plan du sprint comparé à la réalité du terrain.
En Agile, on utilise des techniques d’estimation relative(poker planning, taille de T-shirt, Ideal Days…etc) et elles ne sont pas des projections sur les délais.
Le seul « délai » en Scrum est la durée du sprint et elle ne dépend pas des estimations mais des contraintes du métier, les événements à prendre en compte pour les releases, la complexités des fonctionnalités et les différentes activités.
Toute l’équipe Scrum peut revoir à tout moment la durée des sprints mais idéalement lors des rétrospectives.
Une estimation permet d’abord à chaque dév d’estimer selon sa compréhension de l’effort nécessaire pour livrer une US par exemple en tenant en compte différents facteurs: son expérience, sa perception de sa complexité, visibilité sur toutes les activités de la conception jusqu’à la livraison(y compris les tests) et les incertitudes(notamment techniques)…etc
Ensuite vient la discussion(le second C des 3C des attributs d’une US: (Card, Conversation et Confirmation) qui est le plus important(par exemple lors des estimations en points que les dévs avec les estimations les plus extrêmes dans les deux sens puissent argumenter ce qui permet à tout le monde d’être conscient de l’effort à fournir pour livrer une fonctionnalité(PBI comme US).
J’essaye de toujours faire prendre conscience à l’équipe(Dev, PO) et ceux qui sont en dehors notamment les managers, qu’il n’y a aucune valeur intrinsèque derrière les estimations(notamment les story points), le but est de s’aligner sur l’effort(pas en jours) pour livrer une fonctionnalité(la seule utilisation après ce sera le calcul de la vélocité moyenne qui pourra ensuite être utilisée pour par exemple projeter et communiquer le nombre de sprints nécessaires à l’instant T pour finir tout ce qui reste dans le Backlog en divisant le nombre de points restants par la vélocité moyenne actuelle).
Bonjour @Djiko@jplambert et @Scrummer_Senschool
Merci beaucoup pour vos réponses Après une première lecture, c’est plus clair pour moi
Bonne journée à vous
Après une première lecture, c’est plus clair pour moi