Quand les dev refusent d'estimer.... Que faire?

Bonjour

Ça fait un petit moment que je suis complètement sous l’eau mais dès que je sors un peu ma tête, ma première reflex est de revenir ici :slight_smile:

Je suis depuis quelques mois SDM chez un éditeur de logiciel. En gros, j’accompagne le client dans l’utilisation de notre produit et analyse/ réalise les besoins d’évolution. J’ai avec moi une équipe technique de 8 pers.

Nous ne travaillons pas (encore) en agilité. Chaque besoin d’évolution est exprimé sous forme d’une jira ou un Epic de plusieurs jira. Tout est traité en mode best effort de l’équipe technique, en fonction des priorités exprimés par le client.

Jusqu’à maintenant, le client exprime une date de réalisation souhaité de son côté et l’équipe technique fait avancer le sujet comme ils peuvent de l’autre côté. Donc le planning n’est pas toujours respecté car on n’a pas forcément vu que le ticket est compliqué, le client n’est pas forcément disponible quand les dev ont besoin des explications etc. Je souhaite ajouter la notion de complexité à chaque ticket pour mieux évaluer le ROI , pour mieux prioriser les sujets, pour aligner la dispo de tout le monde etc… Mais mon équipe technique refuse catégoriquement de donner une note de complexité, de peur d’être jugés de leur compétences et de devoir s’engager sur une date de réalisation.

Avez vous des conseils à me donner dans cette situation afin mieux gérer la situation ?

En complément d’info, chaque mois, le client a une liste de priorités à réaliser, parmi une longue liste des choses à faire. J’ai à terme souhaiter créer une sorte de sprint d’un mois avec les objectifs à réaliser = les priorités. Mais sans une estimation technique, c’est compliqué de savoir ce qu’on est capable de réaliser dans le délai imparti

1 « J'aime »

Je t’invite à faire confiance à tes développeurs.

Et fait en sorte d’avoir la confiance des clients.
Les estimations n’aideront pas à avoir cette confiance.
La seule manière de l’avoir est de livrer souvent les sujets à hautes valeurs. D’importants sujets indispensables de tes clients.


L’estimation n’aide pas à savoir ce que vous êtes capable de réaliser dans le délai imparti.

La seule chose qu’on est de travailler chaque jour sur le sujet le plus important et indispensable pour votre client.


Cette liste est ordonnée. La meilleure chose à faire pour votre équipe est de prendre le premier sujet en haut de de cette liste, le réaliser et le livrer. Ensuite, faire de même avec le suivant.

À la fin du mois, les sujets les plus prioritaires seront terminés.

Si vous y arrivez à faire cela, alors vous êtes déjà plus agile que du scrum mal appliqué.


S’il vous est possible de découper les sujets en fine tranche verticale, puis de demander au client de les ordonner de manière relative les un par rapport aux autres.


Si vous respectez le planning, c’est que vous avez gagné au loto. Ce n’est pas ironique, mais la pure vérité. Car, il est impossible de prédire le futur.

Vous avez une date de livraison fixe, à cette date, vous montrez ce que vous avez pu réaliser.

La seule question à répondre :

Est-ce qu’à la date de livraison, vous êtes capable de terminer au moins le sujet en haut de la liste ?

Tout le reste n’a pas d’importance.

Non. No-estimate c’est bien, mais faut en connaitre les limites. C’est pas parce qu’on est incapable de donner des dates précises sur des sujets qu’on est incapable de donner un ordre d’amplitude sur les dits sujets. Et il y a des décisions stratégiques et politiques qui dépendent de ces ordres de grandeur. De plus, un système n’est pas une « pile de features ». Une capacité isolée peut très bien ne faire aucun sens business toute seule.

Je vois nul part le fait que cette liste est ordonnée.

C’est faux aussi. Un système ne se résume pas à une somme de parties encore une fois.

« Ce serait cool une banque où on pourrait faire que des dépôts ! » <= Je vois aucune entreprise dire ça.

Si vous respectez le planning, c’est que vous avez gagné au loto. Ce n’est pas ironique, mais la pure vérité. Car, il est impossible de prédire le futur.

Je peux prédire ce que je ferai dans 1h avec une très bonne exactitude. Je ne peux pas prédire ce que je ferai dans 2 jours exactement car je serai dans un festival, mais il y a une grande chance que je sache. Je ne saurai pas dire au boulot dans 10 jours ce que je ferai exactement et si j’aurai fini un truc. On peut prédire le futur proche (ça s’appelle l’analyse prédictive en statistique) et donner un pourcentage de chance de l’atteindre (ex : prévision avec le modèle Monte Carlo). Donc on peut prédire une partie du futur. Mais ça, c’est un autre débat :wink: Désolé d’être un relou de statisticien hahaha !

Par contre, j’ai une question pour toi Hahn… C’est quoi ton VRAI problème ? Juste que le planning ne soit pas respecté ? Qu’est-ce qu’il se passe pour toi, pour l’équipe, si ce n’est pas respecté ? Parce que je comprends pas le vrai problème ici… ils refusent d’estimer ? Et ? Ils estimaient pas jusqu’avant et ça marchait un peu, j’ai l’impression ?

2 « J'aime »

J’aurais dû préciser, chaque ticket est traité par unique une personne et pas toute équipe. Quand un nouveau ticket apparaît dans le backlog, le responsable de l’équipe technique désigne la personne qui le traite en fonction de compétence technique nécessaire.
Chaque personne de l’équipe a une ou 2 compétences clés. Pour l’instant, ils refusent de faire du transfert de compétences car l’équipe est encore jeune (moins 1 an d’ancienneté) et chacun souhaite perfectionner dans leur spécialité avant de s’intéresser à d’autres choses.
J’ai une petite idée de qui sait faire quoi mais c’est quelque chose ils refusent de communiquer au client. Quand ils partent en formation, nous ne sommes pas forcément au courant non plus quand ils ne sont pas disponibles et sur quoi ils sont en train de monter en compétences. Ils ont beaucoup de préhension d’être jugés par le client.

Le client a une liste des fonctionnalités à faire, avec la priorités. Le responsable technique dispatche cela à son équipe et les gars commencement à travailler sur ce qui est le plus prioritaire de leur liste et chacun se débrouille avec son ticket.
Comme nous n’avons pas de sprint, les gars font avancer les sujets comme ils peuvent et prennent le temps nécessaire pour réaliser ce qui est demandé dans le cahier de charge. Cela peut prendre plusieurs semaines voire plusieurs mois, on ne sait pas à l’avance.

Un côté, le client ont besoin d’avoir une idée du délai nécessaire pour organisation de leur côté, de synchroniser avec les besoins métiers… De l’autre côté, je souhaite aider le client à prioriser les tickets en mettant en avant le ROI. Pour l’instant, si un ticket est très compliqué, on bosse quand-même dessus, on casse les dents aussi longtemps qu’il faut pour le réaliser. Moi, je souhaite regarder si ça vaut le coup de faire, est-ce que la valeur apportés vaut l’effort, est-ce-qu’il n’y a pas une solution de contournement « un MVP » etc à proposer avant de foncer dans la réalisation. Et cela sans qu’on me dise si le ticket est compliqué, pourquoi, combien de temps ça risque de prendre etc, je ne sais pas comment y arriver. Sans compter parfois on apprend que la semaine suivant, la personne qui travaille sur le ticket.
Et je souhaite aussi de créer des sprints pour que, au lieu de chercher à réaliser tous les exigences du cahier des charges, on se dit quels sont les exigences avec plus de valeur qu’on peut réaliser dans un délai donné.

J’espère que ces explications soient suffisamment claires et que vous voyez mieux où je veux venir :slight_smile:

Frédéric Leguédois en parle

Toujours et encore lui.

Savoir choisir ses combats

Bien évidement, comme l’a bien dit @Samuel_Abiassi

Cependant, il faut savoir choisir ces combats et connaitre son rayon d’action.
Les petits pas s’appliquent aussi pour l’amélioration des processus de travail.

L’excellence technique : La base de la base

Est-ce qu’estimer aide les développeurs à être meilleur ?

Au contraire, dans ton contexte, cela peut avoir l’effet inverse.
L’estimation devient un engagement. Comme l’a dit Samuel.

Mince, toutes ces décisions basées sur des estimations moins fiables que les prévisions météo à un mois.
Qui ferait un investissement de 1M € basé sur une prévision météo à un mois ?

C’est la grosse pression, pour les développeurs, si ça foire ça va retomber sur eux.

Est-ce qu’estimer aide à découper au plus fin un sujet ?

Pour un découpage vertical, dans ton contexte, il y a seulement le client qui peut juger si c’est livrable.

C’est sûr que pour découper au plus fin, il faut très bien connaitre les besoins des clients.

  • Pour challenger et poser les bonnes questions.
  • Mettre en place les métriques qui vont permettre de mesurer ce qui est important.
  • Pour enfin, prendre des décisions produit et ordonner le backlog.

Pour arriver à ce niveau, il y a beaucoup de chemin à parcourir.

1 « J'aime »

J’aurais dû préciser, chaque ticket est traité par unique une personne et pas toute équipe. Quand un nouveau ticket apparaît dans le backlog, le responsable de l’équipe technique désigne la personne qui le traite en fonction de compétence technique nécessaire.

C’est toujours le cas dans beaucoup d’équipes « client-fournisseurs ». Et j’imagine que c’est exactement le cas ici. On a un client qui a sa liste de priorités, qui « pense savoir ce qu’il veut ».

Le « vrai » soucis, c’est que le client veut avoir une « idée » du délai, et de l’autre les développeurs ont peur de devoir estimer et donc d’avoir des « deadlines » et qu’on leur mette la pression. Et aussi de savoir s’il faut faire le ticket ou pas, s’il est trop complexe, si le ROI est intéressant, etc…

C’est un cas très complexe et je pense que n’importe quel conseil donné ici aura peu de chance d’aboutir : c’est clairement un cas de consulting / coaching qui me semble difficile de répondre ici sans risquer un danger. Par exemple, c’est bien beau de parler de #noestimate, je suis pour le modèle même s’il a ses limites aussi (comme tout modèle…), mais… Ca me semble extrêmement difficile de le mettre dans une équipe qui fonctionne en mode « client-fournisseur » !! Autant aller vers une autre direction qui répondra à minima au problème.

Le seul « conseil » pour avoir vécu ça qui me vient c’est : « parles-en à ton équipe ! » Explique leur les soucis de ton client. Explique leur ton soucis à toi. Parlez-en à coeur ouvert.
Et aussi, crée des liens forts avec ton client, que tu veux l’aider dans son problème.

Dans l’idée du modèle « Agile Fluency », vous êtes a priori en « pré-agilité ». La première étape, c’est de mettre en place un vrai cadre de travail en priorisant par la valeur et en présentant aux parties prenantes clés (pas forcément juste le client) les travaux effectués pour avoir un feedback le plus souvent. Si les dévs ne veulent pas estimer mais que le client veut avoir une idée de délai, faut en parler avec les dévs et avec le client directement, voir encore mieux si c’est possible tous ensemble dans une réunion !

3 « J'aime »

@BenjaminF @Samuel_Abiassi @Alexandre_Quercia

Merci de vos analyses et conseils.
Je me rends compte que je suis quelqu’un qui aime améliorer, expérimenter de nouvelles méthodes et le changement ne me fait pas peur, bien à l’inverse. Cependant, ce n’est pas forcément le cas des personnes autour de moi et mes initiatives ne sont pas toujours compris.
Je vais tenter à communiquer encore davantage comme vous avez conseillé, mais je dois aussi travailler ma patience
C’est tellement cool avoir des points de vue de l’extérieur :heart_eyes:

1 « J'aime »

Hello,
Ne pas estimer ne veut pas dire ne pas savoir où on va, où on en est, et à quelle vitesse avance l’équipe.
Dans mon entreprise, j’ai deux devises : arrêtez d’estimer, codez, ça c’est pour les DEVs et pour les autres, arrêtez d’estimer, mesurez

La mesure est la clé de l’équipe, c’est la seule chose qui est fiable. La passé est une mine d’or, mais rarement exploité. Sur jira, tu peux mettre des indicateurs de débit qui va te donner un rythme. Évidemment, les congés, formations, maladies vont pondérer cette donnée mais elle va te donner plus de chose que n’importe qui, qui se dirait avoir la compétence de prédire l’avenir, car c’est ça estimer.

Après, certains comptent des story points, d’autres la valeur metier, moi je préfère parler juste de carte.
Et du coup, le travail intéressant de l’équipe est de découper chaque besoin en un truc qui aurait une taille étalon. Ce qui donnera plus de fiabilité à ton debit et tu vas commencer à devenir prédictible.
En general, pour un sujet de cette taille, on a mis autant de temps.
Le tout est de trouver la bonne pratique de découpage, surtout pas technique, verticale, qui a du sens pour le metier, rapidement testable.

2 « J'aime »

Si je comprends bien, actuellement aucune estimation n’est faite. Est-ce exact ?

J’ai une petite idée, de formaliser ton interrogation sous forme de User Story. Je me rends compte que les questions de @BenjaminF cibles beaucoup la partie afin de.

La partie afin de est la plus importante, elle doit être comprise.
La partie je souhaite est juste une idée, il se peut qu’il y ait d’autres manières d’accomplir le afin de.


La courte version :
En tant que SDM, afin de respecter le futur prédit par le client, je souhaite mettre en place les estimations.

@Hanh_NGUYEN en tant que SDM,

Afin de

Ma reformulation : afin de respecter la date exprimée par le client. Autrement dit de manière plus clache : Respecter le futur prédit par le client.

Tu souhaites

Ma reformulation : Mettre en place les estimations.

Ce qui permettra de

  • D’augmenter de 999% le ROI de l’équipe. (C’est fictif).

Avec ce format de support, je peux poser des questions pour creuser ma compréhension du :

en tant que.

  • En quoi, le fonctionnement actuel limite ton travail de SDM ?

afin de.

  • Qu’ont besoin les clients, d’avoir les fonctionnalités à date ou d’avoir confiance que l’équipe travail sur le sujet le plus important pour eux ?
  • Quel problème concret cela crée que telle fonctionnalité ne soit pas terminé à date ?
  • Respecter la date est-il si important et indispensable ?
1 « J'aime »

Perso, j’aime la notion de date, le client vous dit combien il est prêt à dépenser pour cette fonctionnalité.
Si vous decoupez la fonctionnalité en la version la plus importante possible pour 2 à 3 jours de dev, ça devient intéressant.
Quand la date approche, l’equipe a réalisé ce qui était le plus important pour le client dans le temps et donc budget qu’il était prêt à mettre pour la fonctionnalité.

Pour moi, c’est ça le début de l’agile.

@TheLimande La plupart de nos Jiras sont indépendantes, mais nous avons très souvent des grandes Jiras pour lesquels nous avons du mal à découper plus fine. À savoir que, une des caractéristiques de notre produit est qu’on a énormément de dépendance entre les paramétrages. Une rubrique peut être utilisée à plusieurs endroits et le fait de modifier l’un peut faire beaucoup de régression ailleurs. Nos dev ont la tendance de regrouper des jiras de la même thématique pour traiter en même temps. De ma fenêtre, tant qu’ils arrivent à faire des évolutions sans faire de régression, je leur fais confiance sur le plan technique et la façon de faire. Cependant, la complexité n’est jamais mesurable et évolue en fonction de l’avancement

Dans ma réflexion, je dirai qu’il faut qu’on challenge mieux les besoins du client pour pouvoir leur proposer quelques choses juste à leur besoin tout en étant transparent sur nos limites de compétence, contraint des ressources… Mais je vois que les dev sont toujours très prudents au contact client. Il faut que j’arrive à les faire ouvrir plus.

@Alexandre_Quercia s’exprimer sous forme de US est une bonne idée. Je tenterai de reformuler ma demande dans ce sens.

Etant SDM, je suis l’interface entre notre équipe technique et notre client. Notre client recoit des demandes d’évolution, modification de leurs services interne. Je collabore avec notre client dans la découverte des besoins, reformule et transmets le besoin auprès de notre équipe technique, arbitre la priorité des sujets et définir le planning avec le client, coordonne l’avancement des activités des 2 côtés, de la découverte des besoins jusqu’à la recette postproduction chez le client. En parallèle, je gère les communications interne / externe, animer les workshops, la facturation etc… La limite de ma fiche de poste est « fais ce que tu juges à faire, tant que le client est content, on est content » (parole de mon directeur). Donc, j’ai fait pas mal d’initiative depuis mon arrivée. Il parait qu’avant, la relation entre les 2 parties était électrique et le client a demandé de changer les 2 SDMs avant moi. On m’avait prévenu que le client est difficile à satisfaire, mais j’ai vu en face de moi des personnes très collaboratives, très à l’écoute, très agréable à côtoyer professionnellement aussi bien qu’humainement parlant. Jusqu’à maintenant, toutes mes propositions sur notre façon de travailler sont plutôt bien accueillies par le client, mais j’essuie souvent des blocages de notre côté. L’équipe technique est très réticente, malgré des efforts à répétitifs, à les faire sentir mieux concerné du projet ou plus proche du client (personne ne veut m’accompagner en déplacement chez le client, quand je partage des infos du comité de pilotage ou des projets à venir, ils se plaignent que ça les concerne guerre…).

Avez-vous des conseils pour progresser dans cet axe ?

Juste pour ma culture, c’est quoi un SDM?

Une US qu’on ne peut pas découper n’est pas une US et est donc inestilable et impredictible.

Tu as un exemple concret?
Pour moi, il vous manque une pratique agile de découpage (backlog refinement)

Quant aux régressions, vos devs ne font pas de TDD ou mieux, BDD?

« Services delivery manager » ou « Responsable de Production et services » en Français, quant à mes fonctions, j’ai décrit un peu plus haut.

Je vais tenter de t’expliquer : souvent on commence par développer une prime X. Cette prime est repris plus tard pour calculer les autres avantages Y,Z. A un moment donné, le métier nous demande de modifier X pour être conforme avec les lois, les conventions , les accords…en déclinant X en X1, X2, X3pour chaque situation. Donc, nous on modifie X. Cependant, Y,Z ne s’évoluent pas pour autant. Donc, ils préferent de tout corriger en meme temps car les X1,X2,X3 sont dépendants entre eux et les Y,Z aussi. Je ne sais pas si c’est suffisamment clair, je suis gênée de nommer telle ou telle prime et si je rentre dans les détails des dépendances, ca risque d’être très long :frowning:

Pas du tout, ils développent puis ils testent avec des cas de tests fournis par le client (je participe également dans la construction de ce cahier de recette)

ok, je connais bien ce genre de cas, je travaille dans la banque et assurance :wink:
en fait, si tu découpes ton besoin en cas métiers (Use Cases) tu peux faire prioriser à ton client les cas qui arrivent le plus souvent dans la vraie vie. Et donc coder le cas le plus rentable avec le plus fort ROI tout de suite. et ainsi de suite jusqu’à couvrir tous les cas en avançant avec une transparence de rythme et de budget : genre faire une démo au client tous les 15 jours, même si vous n’avez pas avancé beaucoup ou vous êtes bloqués
cela permet de montrer le rythme de l’équipe, pour cette argent, ils produisent ça de montrable et ils ont ça comme blocages.
si en plus tu priorises par la valeur, il a tout de suite quelque chose qui parle.
on n’a pas besoin d’être agile pour faire tout ça, le mode itératif priorisé par la valeur fonctionne très bien.
la priorisation par la valeur, c’est ce que moi j’appelle découpage vertical plutôt que horizontal (par stack techno)
il y a plus de 20 ans, on faisait déjà comme ça sans savoir que ça servira un jour pour le découpage et priorisation agile. on parlait Use Case, modélisait des entités métier avec le métier pour mieux identifier les données qui feront des dépendances entre les Use Cases, ce qui arrive aujourd’hui entre les US

je sais pas si tu me suis ?

concernant TDD et BDD, je comprends mieux
en Agile et Craft nous poussons l’excellence technique dont le développement piloté par les tests
mais en cycle en V (bouh) on a aussi le droit de chercher le côté Craft pour tous les développeurs.
ça fait gagner tellement à toute l’équipe, les TNRs automatisés, la moindre régression est vue avant de livrer car des tests cassent. c’est un vrai investissement pour le future qui rend l’incident moins cher.
votre client fournit des tests, parfait, scriptez les avant de coder, quand ça passera vert, c’est que ça marche, et si ça passe rouge plus tard, c’est que tel ou tel développement a cassé cette fonctionnalité.
ça veut pas dire qu’il faut corriger vite fait sans rien dire, mais ça ouvre le dialogue entre les devs et toute l’équipe y compris le métier : en codant cette fonctionnalité prioritaire, on a cassés ces cas d’utilisations, est ce normal, on corrige comment ? et hop, on ajuste le script cassé pour que le script soit toujours en phase avec comment ça doit marcher

tu peux même aller plus loin avec la pratique BDD, en générant la documentation des scripts implémentés et diffusé avec l’équipe. tout ça existe depuis longtemps, c’est éprouvé, et ça porte ses fruits :wink:

SDM, ok, chez moi, le rôle que tu as décrit se rapproche du Product Manager voir le Product Owner