Les Pro. de la Transfo.Youtube CIO Révolution by AirsaasPodcasts Apple CIO Révolution by AirsaasSpotify CIO Révolution by AirsaasDeezer CIO Révolution by AirsaasCIO Révolution by Airsaas
En collaboration avec
AirSaas content
Alliancy
En collaboration avec
AirSaas content
Valiantys
En collaboration avec
Podcast LPDTAlliancy
e
81
Saison : L’agilité dans l’entreprise en 2023

Comment répondre différemment au besoin d’estimation ?

La vraie transformation agile commence lorsqu'on arrête les estimations

Écoutez l’épisode sur votre plateforme préférée

Youtube CIO Révolution by AirsaasPodcasts Apple CIO Révolution by AirsaasSpotify CIO Révolution by AirsaasDeezer CIO Révolution by Airsaas

Le podcast en résumé

Bienvenue dans votre épisode n°81 du  podcast CIO Révolution by AirSaas saison spéciale : L’agilité dans l’entreprise en 2023 en partenariat avec Valiantys - Atlassian Platinum Solution Partner

Pendant 1 heure, notre invité coach et conférencier agile va vous faire oublier l’approche prédictive et sa fameuse “boule de cristal”  trop souvent associée au métier du développement logiciel. Repartir sur une approche rationnelle pour se concentrer sur la valeur, la transparence, le feedback, la confiance 🙏, le produit et l’équipe ! Une plongée profonde dans les mythes et paradoxes de cet exercice de style que sont les estimations.

Notre invité : Frédéric Leguédois…

Conférence de Frédéric Leguédois - Cessons les estimations
Conférence de Frédéric
  • Est coach agile 
  • Conférencier iconoclaste reconnu dans la communauté agile
  • Et fait des formations. 
  • À un background technique / été développeur 
  • À découvert l’agilité au début des années 2000 par le biais de l’extrem programming
  • À créé la société Ex Novo “L'IA et l'agilité au service de votre transformation numérique”
  • Privilégie une approche basée sur la réflexion, l'analyse plus que sur l'application d'une méthode clé en main.

Sa rencontre avec l’agilité

« Tout ce qu’on avait appris à l’école était fracassé par la réalité du terrain complètement différente »

Au début des années 2000 Frédéric a été développeur au moment du boom des télécoms.

Il a alors vécu un contraste saisissant entre la théorie projet et cycle en V apprise à l’école et le terrain 

«  Ce qu'on a, ce qu'on a appris à l'école, ne fonctionne pas non plus, ne peut pas fonctionner. »  

Face à ce bazar Il a  cherché d’autres personnes qui avaient rencontrés ce type de difficultés. Et à découvert “l’extrem programming”. Cette méthode apportait des réponses vraiment novatrices.

Puis un second moment Lorsqu’il a eu l’occasion de créer un équipe de dev sous la direction hiérarchique d’un DA. Avec une totale liberté d’expérimenter et mettre en place des fonctionnements différents pendant 5 ans. « J’ai pu aller très loin dans un fonctionnement agile » 

« Un vrai temps de liberté pour construire des alternatives. » ou son responsable regardait le résultat final et faisait confiance en termes de méthodologie.

1."100% des estimations sont fausses"

Frédéric n’est pas le seul à le dire, mais il le dit souvent et avec beaucoup de convictions ! 

‍« L’agilité privilégie une approche adaptative versus une approche prédictive des méthodes classiques qui partent du principe qu’on vit dans un monde immuable » 

Frédéric rappelle que les choses émergent en permanence : Le besoin, le marché évolue en permanence. On vit dans une certaine forme de complexité.

Loin des amnésies journalistiques, il rappelle que la seule chose qui ne change pas c’est le changement. Et que les successions de crises ont toujours été la norme… On vit une époque ordinaire ou rien n’est prédictible ! 

Pour lui : « L’aspect prédictif ne marche pas. Il ne faut même pas prédire ce qui va se produire dans quinze jours. Il ne faut  pas chercher à le prédire, parce que c'est une perte de temps.

Et il faut substituer à ça, que ça soit sur les délais ou sur l'approche des coûts, quelque chose de purement adaptatif. » 

«  L’agilité c’est l’acceptation que le monde change continuellement » 

« Les estimations de coûts et de délais c’est comme la météo, à la demi journée ça fonctionne.   Mais du coup ça n’a aucun intérêt !  Dans nos métiers prédire à 15 jours c'est déjà très, très ambitieux, pour pas dire pas très réaliste »

En effet…Frédéric nous le rappelle avec humour le matin, si on annonce la météo pour l'après-midi, c'est super fiable...

Le point qu’il soulève est central dans la tech  : « Dans les approches classiques, si on retire les estimations tout s'effondre !  Puisque on va recruter sur la base d'estimations, on va vendre sur la base d'estimations, on va contractualiser sur la base des estimations, on va communiquer sur la base d'estimations, on va prioriser sur la base d’estimations… »

Et dans le même temps, il le confie,  tout le monde lui dit: « oui, ou sait que c'est pas fiable, mais on n'a pas le choix ! »

Pour lui, si on retire les estimations, la question clé à se poser c’est  « comment et à quoi répondent ces besoins d'estimation ». 

Et surtout, étant donné qu’elles répondent à des besoins comment est-ce qu'on peut y répondent différemment ?

2. Pistes pour répondre différemment au besoin d’estimation

Ne pas figer le périmètre, partir sur la confiance et surtout suivre l’activité ! 

Avant tout, Frédéric revient à la base…C’est quoi une estimation ?  … Rappel utile tant trop souvent tous les mots sont “galvaudés”. Une estimation c’est  l'association d'un coût avec un périmètre fonctionnel.  Pour lui c’est un point clé, le périmètre fonctionnel ne peut pas être figé…

Il regrette par ailleurs le fait qu’on a souvent tendance à faire porter sur l'équipe de réalisation le fait que qu’on ne maîtrise pas complètement la complexité. Mais il rappelle que si on fait une démonstration auprès d'utilisateurs, par exemple, ou bêtatesteurs, c'est qu'on s'attend à voir leur retour…ce qui confirme si tout est bien organisé que rien n’est figé !

Il conseille donc de ne pas  aborder le coût par une solution qui serait figée et définie dans le détail, parce qu'en outre on risque de se couper de toutes les opportunités qu'on va découvrir. 

Mais au contraire de partir sur la confiance et suivre l’activité ! Il conseille de communiquer  donc plutôt un coût par problématique qu’on veut résoudre.

Cependant pour lui, gérer la confiance dans un mode adaptatif ne signifie pas non plus faire un chèque en blanc ! Il y a au démarrage une période d’amorce ou on part sur la confiance….mais surtout on suit l’activité.

Outre un planning ou un powerpoint de “l’ancien monde prédictif”… Il y a deux grandes manières de partager l'avancée de ses travaux : il y a la démonstration et il souligne que la démonstration, c'est de manière très concrète, je vous montre ce qui fonctionne et donc en creux, on voit ce qui ne fonctionne pas encore. Et encore plus fort, il y a la livraison.

C’est une conviction : La meilleure visibilité qu'on puisse apporter à un client, c'est de livrer des choses. Et donc si on veut être dans un mode adaptatif, ça se mérite. C'est-à-dire qu'il va falloir avoir un fonctionnement où on va être capable idéalement de livrer très rapidement ou au moins de démontrer très rapidement pour que le financeur, le client, la direction en face ait confiance en se disant

 « OK, j'ai des gens qui ne sont pas forcément capables de me dire précisément où on en sera dans huit mois, mais de toute façon la direction sait très bien que c'est pas possible de le savoir. Par contre, j'ai des gens qui sont capables tous les quinze jours de me montrer des avancées concrètes et ça avance bien. Donc dans ce cas là je fais confiance. »

En un mot comme en mille, Rester focus sur  : «  On prend le besoin, on développe, on teste, on livre »  

Plus d’estimation ? Quel objet commun de communication ?

Si on retire les estimations…C’est le plus petit périmètre fonctionnel. C’est à dire quelque chose qui va être utilisé par les utilisateurs qui devient le dénominateur commun.

Attention point de vigilance : quelque chose qui est petit et fonctionnel. Pas quelque chose de technique !

“Ce qu’on va chercher c’est quelque chose sur lequel les utilisateurs peuvent faire des retours”.

Une autre  structuration de la roadmap

Pour Frédéric une autre approche  serait par exemple de dire : “sur ce premier semestre, on veut s'attaquer à l'accessibilité de notre site internet.”

Ou bien sur ce second semestre. On veut améliorer la sécurisation, ou :” on veut améliorer notre conformité aux règles de la CNIL” ,…en clair partir de vraies problématiques.

Il souligne qu’effectivement, ce n’est pas un chèque en blanc !  Il conseille de dire:  on souhaiterait avoir une démonstration tous les mois…« Il faut vérifier que ça marche sur le terrain ! » 

Il ajoute qu’“Entreprendre sans risque ne marche pas” 

Frédéric insiste sur le fait qu’il y a une contrepartie…C’est la transparence !

Cette équipe doit pouvoir à la demande de la direction, tous les mois, tous les trimestres ou les six mois présenter l'avancée des travaux, les difficultés, etc. 

«  L’arrêt des estimations c’est pas annoncer l’arrêt de la transparence bien au contraire. Mais simplement, on va pas annoncer le futur, on va présenter ce qu'on a fait. »

Notre conférencier adepte des phrases a impact…le rappelle  : « Le planning n’a jamais fait le délai. »👍 

Il souligne que ce n’est pas parce qu’une équipe, notamment dans des grandes entreprises, va annoncer que quelque chose sortira à telle date que ça va se produire comme par magie ! 

Néanmoins Frédéric le reconnaît  « Si le périmètre fonctionnel est ouvert et  que l'objectif chiffré n'est pas trop ferme, ça fonctionne !»

Cependant étant donné qu’il y a un peu d’inertie au démarrage d’une équipe, Frédéric  ne recommande pas forcément Au début de commencer par quelque chose qui est le plus important et qui a le plus de valeur.

Plutôt un petit truc simple histoire de s’échauffer…Avant d’aller sur le fonctionnel qui a le plus de valeur pour les utilisateurs.

La stabilité de l’équipe et le dialogue soutenu avec l’équipe étendue

Sur la question de l’équipe et de la com avec les métiers, pour Frédéric l’enjeu clé pour se synchroniser avec des personnes en dehors de l’équipe, c’est le dialogue soutenu pour une synchro régulière. Un dialogue avec comme prérequis l’intégration à temps partiel et ou à temps plein en fonction de la charge du contributeur qui rejoint l’équipe…

Il évoque enfin l’importance de ne pas avoir (trop) d’intermédiaire …pour que les équipes se parlent et se parlent en direct ! 

3. Démotivation, burn out, mauvaise qualité et gâchis financier : Les effets néfastes associés aux fausses “deadline” 

Le fonctionnement prédictif a des effets toxiques pour les collaborateurs, les projets et votre budget.

  1. La démotivation

Le premier effet néfaste, c'est que si on fixe des objectifs, mais qui ne sont jamais atteints, alors que l'équipe est hyper impliquée, On va mettre systématiquement l'équipe en échec. Et une équipe qui part d'échec en échec un moment va être démotivée.

Frédéric le souligne les deadlines pour motiver les gens… Ça marche très bien avec le petit jeune qui sort de l'école…Pendant six mois. ! 

Avec des profils seniors qui savent très bien que le truc est pas très rationnel. Il est probable qu'on les motive pas.

Et tout ça peut amener des départs et ou burn-out !

Au contraire plus on va avoir une équipe stable plus on va avoir de la performance…rappelle t-il.

  1. La mauvaise qualité 

Le deuxième aspect: si on met une deadline très forte, les gens vont la tenir mais la qualité va passer à la trappe et donc là, on aura un problème.

« C’est assez incroyable à quel point il y a beaucoup d'organisations qui défendent finalement ce système basé sur des estimations qui n'ont aucune abaque »

on peut avoir quatre-vingt-dix-huit pour cent des estimations qui sont fausses. Et puis quand elles sont fausses, on s'aperçoit parfois qu’elle sont fausses jusqu'à trois cents, quatre cents, cinq cents, six cents, sept cents % fausses.

Et dont tout le monde a un peu conscience que le truc est bancal. !  

Il cite l’Exemple d’une équipe accompagnée… qui sur 50 sprints en 2 ans ….n’avait eu que deux estimations justes.  “Il y a un vrai risque à faire ça… !” souligne Frédéric. 

  1. Le gâchis financier

Le troisième problème le gâchis…. «  Ça coûte un pognon de dingue ! »souligne Frédéric avec humour ^^

Oui on l’évoque peu. Ce temps passé à faire des estimations, le temps de justifier les estimations, le temps de justifier pourquoi les estimations ne sont pas tenues, le temps de faire une réévaluation des estimations, d'expliquer pourquoi est-ce qu'on décale, etc. Pendant tout ce temps-là on ne travaille pas. ! 

On  sous estime ça… Mais,  “quand on rentre dans un fonctionnement sans estimation, tout devient beaucoup, beaucoup, beaucoup plus léger et beaucoup plus simple” affirme notre conférencier avec conviction..

Les plannings meeting et retros…vont vite te prendre 10% du temps…au cours duquel on ne fait pas ce pourquoi on travaille…

Ce qui le fait vraiment c’est la qualité du produit.

En un mot comme en mille, Rester focus sur  : «  On prend le besoin, on développe, on teste, on livre »  

Résumé - Une approche adaptative vs le "doigt mouillé"

L’idée force est bien de ramener de la rationalité dans nos métiers… Frédéric préconise donc cette approche adaptative plus rationnelle vs le doigt mouillé !

Expérimentons et mesurons ! Dans des activités finalement plus proche de la R&D comme le développement logiciel.

Un peu comme les modèles toutes les estimations sont fausses mais elles fonctionnent aussi pour stimuler et mettre en mouvement, à l’image des sportifs qui se fixent des objectifs …Atteignables. C’est un peu le paradoxe que je retiens après l’écoute de cet épisode garanti 100% convictions et 0 bullshit !  

Références

 « L’Extreme Programming : Avec deux études de cas » par Jean-Louis Bénard, Laurent Bossavit, R. Medina et D. Williams.

Le site de Frédéric : https://exnovo.io/

Time line de l'épisode :

  • 2:08 La rencontre de Frédéric avec l’agilité et l’extrem programming
  • 04:30 Tout Ce qui est costing (fin ou macro)…ne fonctionne pas !
  • 08:45 Comment répondre différemment si on retire les estimations.
  • Aborder les estimations par le coût par objectifs et problématiques qu’on souhaite résoudre.
  • 12 accepter « l’impredictibilité »
  • 14:45 l’objet commun de communication si on enlève les estimations ? : le plus petit périmètre fonctionnel
  • 21:20 Amazon Facebook, google, aucun grand projet n’a commencé grand !
  • 25:07 L’exemple de projet le plus agile qui soit…
  • 28:50 « Faire un journal des découvertes »
  • 31:02 Ne pas oublier le facteur humain et les interactions…le projet ne prime pas sur l’humain !
  • L’arrêt des estimations c’est pas l’arrêt de la transparence
  • 34 Quelle structuration de la roadmap ?
  • 38:00 Les abaques et le degré de confiance dans les estimations
  • 40 les effets néfastes associés aux estimations
  • 46:00 une anecdote sur une équipe scrum accompagnée en échec 50 sprints…2 bonnes estimations.
  • 50:50 Une expérience pour prendre conscience de l’inutilité des roadmaps actuelles
  • 57:45 Comment communiquer sur les fonctionnalités ?
  • 1:00 Se synchroniser avec les personnes hors de l’équipe


No items found.

La video du podcast DSI

Le podcast en transcription

linkedin
Bertran Ruiz
CEO AirSaas

CIO Révolution : Le podcast des DSI modernes

Le podcast pour comprendre comme le métier de DSI est en train de changer. D'un métier technique à un métier orienté business, le DSI est la clef de la transformation de nos entreprises.

Chaque semaine, Bertran ruiz discute avec les CIO et DSI qui se livrent, et vous partagent leurs expériences. Un condensé de savoir et d'apprentissage.

Les derniers épisodes du podcast