Dans le développement logiciel, l’estimation des fonctionnalités est souvent considérée comme un mal nécessaire. Elle peut prendre du temps et conduit très souvent à des estimations fausses. Le mouvement « No Estimate » a émergé en réponse à ces problématiques, offrant une alternative à l’estimation traditionnelle. Dans cet article, je vous présenterais ce qu’est le « No Estimate » et je partagerais mon expérience de 3 ans de pratique en startup.
Définition du « No Estimate »
Le « No Estimate » est une méthode d’organisation de projet agile dans laquelle les développeurs travaillent sans estimer le temps nécessaire, pour accomplir chaque tâche ou fonctionnalité. L’accent est mit sur le découpage fin des fonctionnalités et leur priorisation, en travaillant en étroite collaboration avec les parties prenantes et les utilisateurs finaux.
Cette méthode met l’accent sur la communication et la collaboration en équipe, plutôt que sur l’estimation du temps ou des coûts. L’objectif est de livrer des fonctionnalités de manière régulière et fréquente, en se concentrant sur la valeur ajoutée pour l’utilisateur final. Le temps gagné à ne pas estimer est réinvestit dans la conception du produit mais aussi dans la qualité de sa réalisation.
Retour d’expérience
J’ai travaillé pendant 3 ans et demi en startup en tant que Senior Developer puis Technical Leader de plusieurs squads fonctionnelles.
👶 Les débuts
J’ai eu la chance de rejoindre l’aventure à ses tout début, alors que l’équipe de développement comptait uniquement 3 personnes (moi inclu).
Les débuts ont été assez classiques en Startup : prémisse d’un fonctionnement Agile, backlog très sommaire, et estimation des fonctionnalités en heure. Après quelques semaines, nous nous sommes naturellement rendu compte que les Planning Poker Meeting (réunion d’estimation du sprint à venir) nous prenait beaucoup de temps pour un résultat très peu fiable.
Nous avons donc migrer la méthode d’estimation vers du story point puis du T-shirt size, un compromis acceptable pour l’équipe Produit de l’époque.
Pendant plus de 6 mois, tout allait bien, notre travail en Scrum était fluide et nos sprints semblaient se dérouler sans encombre.
Puis petit à petit, quelques problèmes sont apparus :
- Augmentation du stress dans l’équipe : ayant tous une conscience professionnelle établie, l’engagement de livraison du contenu d’un Sprint est devenu un stress. Améliorer nos estimations et être plus productif lors du Sprint sont devenus des préoccupations centrales.
- Baisse de la qualité : cette pression a eu pour effet de clôturer les user stories de fin de Sprint avec beaucoup moins d’exigences de qualité que celles de l’ouverture des Sprints.
- Fatigue : le stress + la dette à résorber ont nécessité plus d’investissement de la part de l’équipe et donc un rythme non soutenable.
Ces problèmes se sont accentués progressivement notamment car l’équipe s’est mise à estimer de moins en moins bien. La raison ? Le recrutement massif.
📈 Le scaling
En effet, après plusieurs levées de fond successives, la startup a commencé à recruter beaucoup de développeurs pour grossir les équipes. Nous sommes passé de 3 à 80 devs en 1 an et demi. Les équipes étaient restructurées tous les 6 mois, et des nouveaux arrivaient toutes les semaines.
Le principe de l’estimation en story point ou de T-shirt size consiste à créer une référence pour estimer toujours de la même manière les petits, moyens ou gros sujets. Cette référence s’ajuste au fur et à mesure des sprints et est propre à chaque équipe. Or, les équipes étant en constant changement, ces références étaient questionnées en permanence.
Les 12 squads fonctionnelles récemment constituées ont commencé à tester d’autres pratiques. A l’issue d’une rétrospective, mon équipe a proposé de basculer sur une approche « No Estimate ». Le fait que les estimations soient souvent erronées, causait du stress et de la frustration dans l’équipe, que ce soit côté Dev ou côté Produit. Nos objectif : baisser le stress de l’engagement et ne plus perdre du temps à estimer (ou à essayer d’améliorer notre manière d’estimer).
Cette nouvelle approche nous a permis de nous concentrer sur ce qui compte vraiment : la priorisation des fonctionnalités qui ont le plus de valeur pour les utilisateurs finaux. Nous avons commencé à découper nos user stories avec une précision chirurgicale, en se posant plus de questions sur leurs contours et leurs critères d’acceptation. Nous passions moins de temps à estimer, et plus de temps à réfléchir à ce que l’on faisait vraiment. Notre compréhension du domaine métier s’est accrue et ainsi notre productivité.
Après 3 ans de « No Estimate », aucune équipe n’est revenue à de l’estimation et toutes ont conservé voir amélioré leur productivité.
La peur que sans estimation et sans engagement sur un contenu de Sprint les équipes allaient produire moins de fonctionnalités ne s’est pas du tout réalisé, bien au contraire : nous avons pu sortir plusieurs MVPs et grosses fonctionnalités en un temps record, ce qui a donné un avantage concurrenciel très important à l’entreprise.
Comment avons-nous fait ? Est-ce du seul fait du « No Estimate » ?
D’autres leviers complémentaires au « No Estimate »
Le « No Estimate » n’est pas l’unique pratique qui nous a permis d’améliorer notre productivité.
💡 Inclure les développeurs dès le début de la conception des fonctionnalités.
Les développeurs ne sont pas de simples exécutants. De part notre métier, nous sommes capables de poser des questions logiques poussées et nous n’avons pas peur de remettre en question nos certitudes. Impliquer l’équipe de dévelopment dès le travail d’idéation puis lors de conception et la relecture des fonctionnalités, nous a permis de gagner en expertise métier et de cultiver un sentiment d’appartenance. Une équipe motivée, impliquée et proactive est in fine productive.
👣 Développer une culture d’entreprise sur les baby steps et le MVP.
Même après avoir autant grossi, nous avons conservé un esprit startup. Avoir de l’impact auprès de nos utilisateurs, le plus vite possible en maitrisant la complexité. Les nouveaux ensembles de fonctionnalités ont continé d’être pensé et réalisé comme des MVPs, c’est à dire conçus avec un pragmatisme Produit (priorisation rigoureuse) et réalisés avec un pragmatisme technique (tradeoff réfléchis et maitrisés). Une équipe pragmatique a de l’impact business.
😌 Adopter un rythme soutenable
Nous ne sprintons pas, nous sommes dans un marathon. En supprimant l’engagement sur les sprints et en passant sur du Kanban, nous avons supprimé la pression des deadlines pour nous concentrer sur l’importance du moment. Nous sommes même devenu plus agile : capable de changer de sujet du jour au lendemain sans se préoccuper des priorités de la veille. En sanctuarisant une journée technique, nous avons même dédié du temps pour gérer la dette. Une équipe en pleine forme est productive.
⚡️ Recruter majoritairement des développeurs séniors
C’est un choix qui fut très critiqué en interne pendant la première année. Puis, lorsque les équipes ont atteint un rythme de croisière, nous y avons tous vu les bénéfices : une énorme productivité et aucun challenge qui ne peut être adressé. Une équipe compétente sait résoudre tous les problèmes.
Ouverture à d’autres pratiques
Grâce au temps gagné en supprimant les réunions d’estimation, les équipes ont pu expérimenter d’autres pratiques telles que l’Example Mapping ou la rédaction des scénarios d’acceptation des user stories en Gherkin par le Product Manager lui-même. L’objectif restait le même : gagner en fluidité dans les développements et partager la connaissance métier le plus possible.
Avec le temps et notre volonté constante de réduire le time to market, certaines équipes ont même réalisé que Scrum n’était plus forcément la méthode la plus adaptée, et ont décidé de basculer sur du Kanban, en mode flux. Un fonctionnement beaucoup plus adapté à notre volonté d’avancer sur le Continous Delivery : livrer en production à chaque fin de développement de fonctionnalité.
🪖 Quelques résistances au changement
Pour les développeurs et tout le service Engineering, ces changements se sont fait naturellement sans friction particulière. Je pense que cela vient principalement du fait qu’on laisse facilement aux développeurs l’opportunié de tester d’autres pratiques pour augmenter le confort de development (soyons franc nous sommes chouchouté ! Quoique cela dépende des boîtes, ofc).
En revanche, pour certains Product Managers, la transition a été beaucoup plus difficile notamment en raison du fait qu’ils étaient objectivés individuellement sur la quantité de fonctionnalités livrées à chaque sprint. Lorsque nous avons supprimé les estimations, ce sont eux qui se sont mis à les faire en off en vue de constituer leurs objectifs personnels avec leur manager !
De plus, le passage de Scrum à Kanban, n’a pas été fait par toutes les équipe, notamment par celles qui travaillent sur l’application historique, très critique, car les PMs avaient peur que livrer plus souvent amène à produire plus de bugs.
En revanche, les équipes travaillant sur des applications plus récentes et des MVPs ont rapidement compris l’intérêt d’itérer beaucoup plus vite grâce au « No Estimate » combiné au Continuous Delivery.
Résumé des avantages / inconvénients
Voici un résumé des avantages / inconvénients selon mon expérience.
✅ Avantages :
- Permet de gagner du temps en ne passant pas des heures à estimer les tâches, ni à tenter d’améliorer le processus d’estimation
- Supprime la pression de respecter des engagements de livraison qui peuvent être difficiles à tenir avec des estimations imprécises et des équipes changeantes
- Met l’accent sur la priorisation des fonctionnalités qui apportent le plus de valeur à l’utilisateur final
- Favorise le découpage fin des user stories et l’expression des critères d’acceptation
- Améliore l’acceptation au changement lors du passage en flux (Kanban)
➖ Inconvénients :
- Peut entraîner une certaine incertitude dans la planification et l’organisation du travail
- Nécessite une communication plus étroite avec le Product Manager pour s’assurer que les priorités sont correctement définies
- Peut être moins adapté aux projets qui impliquent une collaboration étroite avec des partenaires externes qui ont besoin de prévisions précises (contractualisation)
- Nécessiter une certaine expérience et maturité de la part de l’équipe pour fonctionner efficacement (professionnalisme et proactivité)
Conclusion
En se concentrant sur la collaboration en équipe, la priorisation des fonctionnalités et la livraison régulière de valeur ajoutée pour les utilisateurs finaux, nos équipes ont pu améliorer leur productivité grâce au « No Estimate » tout en réduisant le temps passé à estimer les fonctionnalités.
Si vous aussi vous pensez que votre équipe pourrait bénéficier de cette pratique, essayez là pendant quelques temps et mesurer les effets produits.
Vous serez surpris !
N’oublions pas que chaque équipe est unique et doit trouver la méthode d’estimation, et plus généralement d’organisation, qui convient le mieux à ses besoins et à ses contraintes.
