Bonjour à tous,
Avant tout, je tenais à vous souhaiter tous mes voeux de bonheur et santé pour cette nouvelle année qui commence. Je vous souhaite plein de sujets attrayants et bien veillants…
Je poste aujourd’hui une question qui va en chagriner certains. Mais je ne sais pas comment trop répondre aux exigences posées.
On nous demande de vérifier tous les matins, aux daily, si on va dépasser le budget alloué à un projet ou pas… ça me semble compliqué de demander au développeur : Est-ce que tu penses que tu vas passer plus de temps sur cette US… J’aime pas trop les contraintes que ça apporte. Est-ce que ça veut dire que l’estimation aura par avance inclus le nombre de développeurs, les compétences, le niveau de complexité, une estimation en Jour/homme ?
Autant j’apprécie l’engagment d’une équipe sur le contenu d’un Sprint et le respect d’un Goal Sprint, autant un engagement sur le coût d’une US me perturbe.
Je ne vois pas comment faire un parrallèle entre un suivi et priorisation de Backlog produit et un Pilotage/suivi bugétaire. Comment vous faites vous de votre côté ?
Le rôle des estimations n’est pas d’organiser les moyens de production mais d’évaluer globalement la crédibilité du backlog de sprint, et d’identifier certains cas de figure problématiques :
- Sujet trop complexe qu’on devrait peut-être découper en morceaux plus petits / affiner
- Sujet dont on ne voit pas comment les réaliser et qu’on va peut-être devoir gérer en mode discovery
- Eviter de faire un plan reposant exclusivement sur la parallélisation de petites tâches individuelles
En Scrum l’équipe ne s’engage pas sur le périmètre (= le backlog) mais sur la qualité (= la DOD) et l’objectif du sprint. Il vaut donc mieux se préparer à ajouter des éléments en cours de sprint en cas de sous-charge ou de blocage, ou d’en enlever si finalement certains sujets étaient plus difficiles à réaliser que prévu. C’est d’ailleurs le rôle du daily d’adapter le contenu du sprint pour atteindre l’objectif.
Un estimation précise des charges en j/h est donc un leurre, il y a forcément des erreurs d’appréciation.
L’enjeu c’est d’arriver à prioriser le backlog produit par rapport aux fonctionnalités qui apportent le plus de valeur aux utilisateurs. Ensuite on peut se baser sur les estimations grossières (style poker planning) pour se faire une idée de la complexité, et arbitrer les fonctionnalités qui apportent le même ordre de grandeur en terme de valeur mais ont des complexités plus faibles. Par contre il faut éviter de l’aborder sous l’angle d’un tri par ratio value/points car ça reste un pari. On n’est pas vraiment sûr du temps qu’on va y passer, et on n’est pas vraiment sûr non plus que les utilisateurs vont adopter la feature autant qu’on voudrait …
Je te conseille cette vidéo où Constantin explique l’approche budgétaire très bien :
J’ai pas eu le temps d’éditer mais je voulais ajouter ce point :
Ta structure résonne en terme de coût-périmètre mais c’est une mauvaise approche.
D’abord on ignore si la fonctionnalité sera toujours utile et rapportera la même valeur en fonction du moment où on l’implémente. Ce qui était hier une feature anecdotique peut devenir urgente et rapporter subitement plus de valeur. Ou à l’inverse, l’idée qu’on s’était faite il y a 2 ans peut devenir particulièrement ringarde et faire fuir les utilisateurs. De plus les technos changent très vite et potentiellement les features qu’on implémentera dans 2 ans n’auront pas le même coût du fait que certaines libs seront devenues obsolètes ou alors au contraire que des solutions moins couteuses seront apparues entre temps.
L’approche scrum/agile consiste à résonner en terme de moyens à périmètre variable. Tu connais la composition de l’équipe et le CJM donc tu peux dire combien ton équipe coûte par sprint et par an à faire tourner. Ca gère le côté budget, on sait qu’on en a pour X k€ / an tout inclus.
Ensuite on aborde la question du ROI sprint par sprint en s’assurant qu’à chaque sprint on incrémente la solution d’un jeu de fonctionnalités qui apportent un max de valeur pour le juste coût. Ca nécessite que le management segmente sa pensée financière au niveau du sprint ce qui veut dire moins de visibilité à long terme, mais beaucoup plus de réactivité lorsque le marché bouge. Ca évite de se dire qu’on a immobilisé X M€ sur 5 ans et qu’on pourra pas faire d’investissement avant 2029 alors qu’on en aurait besoin maintenant …
C’est souvent là que ça coince dans les organisations complexes car c’est une révolution à la fois managériale mais aussi en terme de pilotage d’entreprise. Le directeur n’est plus un visionnaire mais un capitaine qui tient la barre.