Introduction

Le mardi 6 février, j’ai eu la chance d’assister à la formation “Par-delà les estimations” menée par Frédéric Leguédois. Frédéric propose une alternative à Scrum et surtout aux estimations, “le no estimate”. Ce n’était pas ma première rencontre avec Frédéric. Quelques semaines auparavant, nous avions eu l’occasion d’échanger sur le no estimate derrière un micro pour notre podcast BeeKoz.

Ce qui m’a poussé à contacter Frédéric, c’est une récente prise de conscience autour des dérives de scrum au sein de projets informatiques et de la contre productivité des estimations qui sont chronophages et fausses.

La journée de formation

Définitions

Nous avons commencé la journée de formation à 9h avec une courte présentation des participants et des attendus de chacun. Puis nous avons commencé par donner notre définition des estimations dans le développement ainsi que les inconvénients, les limites et les avantages. Après les estimations, Frédéric a évoqué Scrum et nous a illustré en quoi cette méthodologie n’est pas si agile que ça. Il s’est appuyé sur les 4 valeurs du manifeste agile et les 12 principes sous-jacents pour nous montrer ce que Scrum respecte et ce qu’il ne respecte pas. Par exemple : Scrum respecte la valeur suivante :  “des logiciels opérationnels plus qu’une documentation exhaustive”. En revanche Scrum ne respecte pas celle-ci : “l’adaptation au changement plus que le suivi d’un plan” car il impose un périmètre figé toute la durée d’un sprint.

Transition vers le no estimate

Comment faire transiter une équipe utilisant Scrum et les estimations pour cadencer son projet informatique vers le no estimate ?

Pour répondre à cette problématique, Frédéric nous a expliqué comment prioriser sans estimer. Pour cela, il faut simplement comparer naturellement les éléments entre eux en fonction du client et de ce qu’il souhaite voir arriver en premier et découper le plus finement possible les premiers éléments.

Le reste des éléments non découpés et non priorisés constituent le tableau Kanban en attendant de devenir prioritaire.

Maintenant que nous savons comment ordonner sans estimer, il faut pouvoir donner de la visibilité et rassurer le client. Deux indicateurs vont être déterminant : la fréquence de livraison et la satisfaction utilisateurs. Il faut pouvoir livrer rapidement, réduire le nombre d’intermédiaires utilisateurs/développeurs et faire preuve d’honnêteté pour garantir une bonne transition vers le no estimate.

Budget, avant-vente et vente sans estimations

La dernière partie de cette formation traite de la partie commerciale et financière. Dans un premier temps, Frédéric nous a montré comment réaliser un budget sans estimer. 

Pour cela, il a mis en opposition l’approche traditionnelle avec l’approche no estimate. Dans la première approche, nous annonçons au client qu’il faudra 60 jours pour telle fonctionnalité et 120 pour cette autre. On communique alors un total de 180 jours tout en sachant que cette estimation est fausse et que le périmètre va changer ce qui provoquera un dépassement des délais et des coûts ainsi qu’une perte de confiance.

Avec le no estimate, l’approche est plutôt de se mettre d’accord sur les thématiques globales de la collaboration en laissant une grande marge au client et proposer des moyens pour répondre aux besoins du client. Le budget pour la réalisation ne sera plus basé sur de fausses prédictions concernant un ensemble de fonctionnalités qui va forcément évoluer mais sur un ensemble de grandes thématiques sans oublier la valorisation de la maintenance applicative. “Une journée travaillée est une journée facturée et une journée facturée est une journée travaillée”.

“Pour arriver à vendre ce budget agile, il faut mettre en avant la souplesse que ce fonctionnement offre, s’engager sur les moyens mis à disposition et donc les coûts associés en présentant les membres de l’équipe et surtout faire preuve d’une grande rapidité en avant-vente avec un POC ou des maquettes montrant notre compréhension du besoin et notre rapidité de livraison ce qui aura pour conséquence de gagner la confiance du client.

Frédéric a clôturé cette journée de formation avec les aspects juridiques autour de la contractualisation avec le client notamment sur l’engagement de moyens mis à disposition plutôt que de s’engager sur le résultat.

Ce qu’il faut retenir

Le développement logiciel s’apparente à une activité de R&D (c’est toujours la première fois que l’on développe un logiciel sinon on l’installerait), et non pas à une activité de production reproductible et prédictible.

En sachant ça, la notion même de planning n’a pas de sens réel avec l’approche no estimate. Dès lors qu’un planning est créé, il est faux. Il faudra ajouter le retard provoqué par ce planning pour arriver à la réalité. 

“Le retard c’est la différence entre le rêve et la réalité. La réalité ne peut pas avoir tort. Un retard, c’est forcément une erreur de planning.”

En plus d’être chronophage, les plannings/roadmaps n’ont aucune valeur pour le client.

Ce qui aura de la valeur à ses yeux, c’est l’écoute de ses besoins et la priorisation conjointe des éléments à venir, la fréquence soutenue des livraisons et la qualité du travail effectuée. Il n’a pas besoin de connaître la date exacte de la prochaine fonctionnalité si vous respectez ces valeurs. Si jamais un client vous pose quand même la question suivante : “Quand est-ce que je pourrai avoir la fonctionnalité X ?”, ce qu’il souhaite réellement c’est être rassuré, avoir la certitude que ce besoin est prioritaire pour vous et pris en charge dans l’équipe. Une bonne façon de lui répondre serait d’accueillir positivement la question, de lui expliquer les différentes problématiques rencontrées, la nécessité d’étudier ces problématiques et de convenir avec lui d’une date proche pour lui montrer l’avancement.

La plupart du temps les clients ne poseront pas ce type de question car ils pourront se rendre compte au plus vite du développement des fonctionnalités grâce au rythme soutenu des livraisons. C’est comme ça que vous fonctionnez vous même en tant que client quand vous souscrivez à des services comme Netflix ou Spotify. Vous payez tous les mois pour un service de qualité avec des évolutions fréquentes sans connaître la date de ces nouvelles fonctionnalités.

Conclusion

Pour faire du no estimate, il faut revenir à l’origine de l’agilité et se concentrer sur ce qui a de la valeur. Ne pas perdre du temps à essayer de prédire l’imprévisible et à essayer de planifier un périmètre en perpétuelle évolution.

A la place des sprints et des estimations, mettre en place un tableau Kanban priorisé avec le client, livrer très régulièrement et accueillir positivement les demandes de changement.

Sofiane OUARAB