Accueil > Méthodes Agiles > Lean Kanban 2015 : #NoEstimates

Lean Kanban 2015 : #NoEstimates

Après un premier billet sur la conférence Lean Kanban, je vais revenir plus précisément sur trois conférences qui m’ont particulièrement marquée, d’abord la conférence sur NoEstimates dans ce billet, puis la reconnaissance et l’entreprise libérée dans le billet suivant.

#NoEstimates par Vasco Duarte

Je suis régulièrement confrontée aux limites et problèmes posés par les estimations. J’ai cependant du mal à voir comment s’en passer. Je suis allée voir cette conférence car j’étais curieuse des alternatives proposées.

Vous pouvez trouver le support de la présentation sur slideshare.

no-estimates-10-new-principles-for-testing-41-638

Dans cette conférence, Vasco Duarte nous a présenté 10 principes dérivés du NoEstimates et très importants pour lui pour le développement logiciel. Je vous retranscris ici ces principes avec les commentaires et anecdotes du conférencier qui m’ont le plus marquée.

Principle #1 Trust your process, or change your process

Estimates are like booby traps.

Si vous ne faites pas confiance à votre système, changez le. Ne cherchez pas à changer petit à petit un système défaillant.

J’ai trouvé ce premier principe étonnant. La plupart des autres conférenciers insistent justement sur le fait qu’il faut faire du changement progressif, étape par étape. Mais je pense que Vasco veut insister sur le fait de ne plus utiliser une méthode qui ne fonctionne pas. La majeure partie de sa conférence sert d’ailleurs à convaincre qu’il ne faut plus utiliser l’estimation.
Il rejoint les autres conférenciers sur le fait qu’il faut pratiquer et expérimenter pour changer.

 

Principle #2 Shorten the feedback cycle

patterns-of-agility-how-to-recognize-and-agile-project-when-you-see-one-18-728

Vasco a analysé les données de plusieurs projets non-agiles:

  • les gros projets ont une phase de tests et corrections désespérés de 3 mois en moyenne
  • les petits projets ont une phase de tests et corrections désespérés de 90 jours en moyenne…
  • et il a trouvé le même résultat pour les projets de taille moyenne : 3 mois de phase de tests.

Ceci montre l’importance d’avoir des retours rapides sur un projet au fur et à mesure. Si vous livrez tous les jours alors vous deviendrez très prédictif.

 

Principle #3 Believe the data, not the estimates

Les données prouvent que les estimations sont vraiment mauvaises. Vasco a compilé des données provenant du rapport Chaos et d’autres rapports indépendants. Ces données, même si elles ne sont pas exhaustives, sont impressionnantes. Sur le périmètre des projets analysés :

  • Plus de 60% des projets informatiques sont en retard
  • 40% des projets agiles échouent ou ont des problèmes
  • 17% des gros projets informatiques se passent tellement mal qu’ils mettent en danger l’existence même de l’entreprise qui les portent

citation_nosestimates

C’est comme si votre banquier vous disait : « J’ai un super investissement à vous proposer. Vous investissez 100 euros, je vous promets que vous avez 75% de chance que je vous rende 75 euros. »

Pourquoi continuons nous à utiliser une méthode avec un rendement aussi mauvais?

 

Principle #4 Use alternatives to Estimate-driven decision making

Les données nous montrent que nous sommes mauvais à l’estimation, mais aussi qu’un projet peut être un succès avec de mauvaises estimations. Il n’y a pas de relation entre la qualité des estimations et la réussite d’un projet.

On peut donc trouver une autre solution que l’estimation.

Being good at estimates is missing the point

Je peux confirmer ça par mon expérience, les projets qui réussissent le mieux sont souvent ceux avec une équipe bien organisée, motivée et qui travaille bien ensemble, quel que soit la qualité des estimations.

 

Principle #5 Test for value first, then test for functionality

Que pouvons-nous utiliser pour prendre des décisions autre que l’estimation ?

Vasco nous dit qu’il est plus intéressant de se concentrer sur la valeur business d’une fonctionnalité plutôt que sur une estimation pour prendre des décisions. Il ne croit pas au backlog, il ne mesure pas le pourcentage de stories accomplies mais la valeur délivrée.

Il a, une fois encore, illustré son propos par un exemple.

Il a coaché une équipe e-commerce très démotivée à cause d’un backlog énorme. Backlog remplit uniquement de petites modifications (changer la couleur d’un bouton,…) sans grande valeur apparente.
Pour y remédier, le PO a décidé de faire un sprint d’innovation. Ils ont décidé de réaliser une fonctionnalité proposée par l’équipe. Ils ont ajouté pour l’utilisateur l’envoi d’un mail de rappel d’achat à la consultation d’un produit. La fonctionnalité a été mise en production à la fin du sprint. Deux jours après, ils gagnaient de l’argent. Cette seule fonctionnalité a généré 250 000 euros dans les premiers 6 mois après sa mise en production.

Imaginez ce que nous pourrions faire si nous nous concentrions sur la valeur plutôt que sur les estimations!

Cela montre aussi l’importance de se concentrer sur des fonctionnalités à forte valeur pour l’utilisateur final et l’intérêt d’écouter les idées venant de tous les membres de l’équipe.

 

Principle #6 Estimate is waste, reduce it’s impact on your business

Le conférencier considère le temps passé à estimer comme un gaspillage coûteux et sans grande valeur ajoutée pour le business. Il admet quand même qu’on ne peut pas toujours éliminer l’estimation, il conseille alors de  réduire son impact sur les décisions prises, de ne pas manager son business avec les estimations.

 

Principle #7 Measure progress only with validated, running software

Je trouve les arguments de Vasco Duarte bons et ils font mouche. Cependant à ce stade de la conférence je suis encore très sceptique sur la mise en oeuvre du NoEstimates. Je pense notamment que cela s’applique difficilement au service informatique. Les clients se basent sur le prix et le planning pour choisir une prestation lors d’une avant-vente, je ne vois pas comment on peut s’en passer.

Encore une fois j’ai l’impression que les idées proposées ne peuvent pas s’appliquer dans une société de services. Et là Vasco Duarte amène un exemple concret du contraire.

Vasco Duarte a réalisé une interview de Sven Ditz, CEO de Sitegeist. Lors d’une avant-vente, plutôt que de faire une estimation et préparer un dossier de réponse, ils prennent le cahier des charges et développent une partie des fonctionnalités demandées. Cela leur coûte moins cher que le temps passé à préparer une réponse classique. Ensuite ils présentent ce qu’ils ont fait à la place d’un devis, et proposent au client: voulez-vous que nous en fassions plus ?
Ils montrent un logiciel qui marche en avant vente, c’est un procédé nouveau.
Maintenant ils travaillent sans contrat, le client paie s’il est content du résultat.
Et pourtant ils sont plus rentables qu’avant…

 

Principle #8 The system where you work has predictable outputs, learn to understand the system.

Si on regarde les données sur une équipe en particulier, on voit que le nombre de stories qu’une équipe réalise dans un sprint est très prédictible. Nous avons donc déjà les données pour être prédictible dans une entreprise, il suffit de les analyser. Quand Vasco va dans une entreprise et commence à visualiser les données, il en déduit toujours un pattern qui permet de prédire un planning.

Vasco nous a présenté les résultats d’une expérience faite sur un projet long de 24 sprints.

Question : qu’est-ce qui est le plus précis pour prédire : l’estimation des story points ou compter le nombre de stories réalisées?

img-noestimates

Les mesures montrent qu’une estimation en nombre de stories est plus fiable qu’une estimation en nombre de story points.

Ces mesures ont aussi été faites sur 21 autres projets.

Question suivante : Quelle différence a le Story Point dans un projet qui utilise les Story Points et NoEstimates ?

Une projection de fin de projet a été calculée avec trois méthodes différentes :

  • estimation avec valeurs 1, 3, 5 points
  • estimation avec valeurs 1, 2, 3 points
  • estimation avec toutes les stories = 1 point

Les dates de fin de projet prévues étaient dans les mêmes 3 semaines pour un projet long de 38 à 42 semaines. Il y avait donc 8% de marge entre les différentes méthodes.

 

Principle #9 Don’t bet your company on poor track record methods, use methods with a proven track record
aka: Hope is a bad management strategy

N’espérez pas devenir meilleur dans la procédure d’estimation, il n’y a pas de données qui confirme que c’est possible.

Le NoEstimates est plus une question de pratique et d’expérience que de théorie.

no-estimates-10-new-principles-for-testing-67-638

 

Principle #10 The transformation starts with you…

La transformation commence avec chacun d’entre nous. Quelque soit ce que vous pensez de NoEstimates et même si votre expérimentation de NoEstimates ne fonctionne pas, imaginez ce que vous allez apprendre en mesurant votre système! Vous serez surpris…

Do your own experiment, don’t believe me, believe your data

Vasco Duarte a bien illustré son propos avec des données et des anecdotes. Il était difficile de ressortir sans remettre en cause le bien fondé des estimations. Cependant je suis restée sur ma faim. Le conférencier a surtout cherché à prouver l’inutilité des estimations et à convaincre l’auditoire de tester NoEstimates. Mais il n’est pas entré dans le concret de sa mise en place. Il est d’ailleurs passé très rapidement sur les derniers points, faute de temps.
Il faudra lire son livre pour avoir plus d’informations.

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


9 − deux =