Poker, Fibonacci et stock

Aujourd’hui j’aimerais parler d’estimations. D’estimations agiles, bien sûr. Elles n’ont rien à voir avec les estimations classiques. Ou du moins, pourrait-on le croire. Voyons cela !

L’un des points marquants souvent évoqué est que l’estimation n’est pas faite par une seule personne, mais par l’ensemble des membres de l’équipe, afin de bénéficier de la sagesse de la foule. En fait, l’estimation collective est utilisée depuis longtemps dans les approches classiques et est connue sous le nom de wideband Delphi. Il est vrai toutefois que la technique est sous-utilisée, beaucoup de chefs de projets préférant « optimiser » le temps nécessaire aux estimations ou ignorant simplement cette technique !

L’autre élément majeur est l’utilisation d’estimations relatives, décorellé d’une estimation en charge. Une approche déjà utilisée dans le Function Point Analysis. Ici l’approche agile se distingue par l’utilisation d’une échelle de précision adaptative qui a donné lieu aux fameux jeux de carte du planning poker

Il reste 2 points à soulever : un point de divergence et un point de convergence avec les approches classiques.

Tout d’abord la divergence. Les approches type Cocomo et FPA tentent d’estimer en comparant les sous-éléments techniques des briques à réaliser. Les briques elle-même étant plutôt de taille importante, d’où la nécessité d’opérer une subdivision. Les approches agiles travaillent aussi par comparaison, mais elles s’évertuent à subdiviser l’élément fonctionnel. Il n’est alors plus nécessaire de décomposer celui-ci en sous-éléments techniques. Bien sûr l’approche agile s’appuie sur le postulat que la solution qui sera retenue va être proche de celle utilisée pour la fonctionnalité référents. Mais cela ne va pas aussi loin que dans le cas d’une décomposition technique qui vérrouille complètement les postulats techniques !

Maintenant la convergence. Il y a bel et bien quelque chose que l’approche classique et l’approche agile appréhendent à l’identique : toutes deux s’efforcent d’évaluer une charge ou une complexité (mais est-ce si différent ?) d’un ensemble de choses à réaliser.

Finalement, la logique de l’estimation agile telle que nous la connaissons ne diffère guère de l’estimation classique : on nous demande de réaliser des pans de fonctionnalités pour lesquelles on nous demande d’estimer si c’est gros ou si c’est petit… Une question qui devrait nous donner à réfléchir concernant une approche où l’on prétend maximiser la valeur ! On dirait plutôt que nous voilà cernés dans une discussion pour optimiser la main d’oeuvre, ce n’est certes pas la même chose. Il est vrai que les prétentions « d’hyperproductivité » de Scrum vantées par Jeff Sutherland n’aident pas tellement à changer le focus du discours…

Ce qui ne va pas dans cette approche

Il y a un certain paradoxe à travailler en itérations « time-boxée » afin d’optimiser la valeur produite à chaque itération, et estimer la taille des fonctionnalités à délivrer.

D’un côté, le découpage temporel de la planification contraint le temps afin de permettre la mesurer de valeur par unité de temps. Mais de l’autre côté, la manière dont nous appréhendons les tâches nous conduit à focaliser la discussion sur la charge et le plus souvent à trouver des options pour la réaliser à l’économie. L’estimation agile ne nous invite pas à :

• Rechercher la partie réellement porteuse de valeur dans une fonctionnalité présentée.
• Découper une fonctionnalité en ensemble élémentaires d’apprentissages et d’hypothèses.
• Rechercher comment obtenir du feedback le plus rapidement possible sur l’hypothèse la plus importante.

La logique estimative ne nous aide pas tellement dans notre quête de la maximisation de valeur. Mais cela ne s’arrête pas là. Elle est aussi un handicap sur plusieurs sujets :

• En associant (comme Scrum le fait) l’estimation et l’engagement.
• En donnant prédominance à la logique de coût et en autorisant de fait celle-ci à devenir un vecteur de priorité.
• En nous enfermant dans une logique de périmètre (et les fermetures de choix associés).
• En permettant une logique des « gros morceaux » qui reporte une partie des responsabilités sur l’équipe de développement.

Enumérés ainsi, ces sujets paraissent certainement un peu mystérieux. Ils ne vont pas le rester longtemps, il est temps de nous y attaquer !

Estimation et engagement

Je me suis longtemps battu contre l’idée qu’une estimation n’était pas un engagement. Dans les projets classiques, j’ai beaucoup illustré ce propos avec le cône d’incertitude [1], bien que cette représentation folklorique ait été ensuite un peu secouée par Laurent Bossavit [2].

Cette représentation met l’accent sur un facteur important : l’interval de confiance est plus large quand on a peu d’éléments sur le sujet, il se resserre ensuite progressivement en même temps que notre capacité d’extrapoler sur ce sujet s’améliore. Bien sûr, cet effet est beaucoup plus marqué pour les projets classiques et plus spécifiquement pour les projets non itératifs.

Je pensais m’être débarrassé de l’interprêtation « estimation = engagement » avec les projets agiles. Apparemment, pas tout à fait. Car si l’on commence un planning meeting scrum par des estimations, il se termine le plus souvent par une bonne vielle règle de trois qui nous donne l’engagement de l’équipe en fonction de sa vélocité. La traduction française de « commitment » qui peut donner engagement ou implication n’aide pas tellement quand on prend le premier choix. Par ailleurs, les derniers textes sur Scrum ont pris conscience de ce travers et préfèrent parler d’engagement (ou implication) sur l’objectif.

Bref, l’estimation est bien l’outil de choix pour enchainer l’équipe au banc de rame. Il faut dépoter de la fonctionnalité, la valeur de cette charge (ou de cette complexité, peu importe) n’est pas le sujet. On est bien dans une logique à l’ancienne !

Quand c’est pas cher, c’est prioritaire !

Prioriser n’est pas un acte facile. Du moins en principe. C’est la ligne d’arrivé d’un processus intégrant des dimensions telles que stratégie d’entreprise, opportunités marché ou développement client. Il n’est pas rare que ces tableaux de bord soient flous voir inexistant. Pourtant il faut prioriser.

C’est souvent dans ces situations qu’intervient le « si je n’ai pas d’estimation, je ne peux pas prioriser ». Ce n’est pas illogique de chercher à prioriser en terme de ROI simplifié (valeur/coût). Mais ça l’est d’éliminer le terme valeur ou de normaliser en prétendant que « tout a la même valeur », signe que quelqu’un ne fait pas son travail…

A partir de là, le travail de priorisation devient une pantalonnade allant de « on va commencer par ça, c’est pas cher » au marchandage du type « je ne comprend pas pourquoi c’est si cher… ».

Là encore, on aboutit hélas parfois à des interactions qui ne sont pas vraiment différentes de ce que l’on faisait avant…

Une affaire de périmètre

L’estimation, qu’elle soit en charge ou en complexité, nécessite que l’on arrête un certain nombre de postulats. Ce faisant, on arrête très tôt dans notre processus de conception les options que nous aurons choisi. Du moins, on ne les fixent pas s’il s’agit d’estimations, mais si l’on parle d’engagement…

C’est bien dommage. Car l’adaptabilité devrait être un trait dominant des projets agiles ! En réalisation, cela passe par des pratiques telles que les options réelles [3] ou le « set-based design » [4], [5] et [6]. Ce n’est pas strictement impossible de changer son fusil d’épaule en cours de route, mais les discussions gravitant autour des estimations de taille rendent cela bien plus difficile…

Au-delà des estimations que l’on fait pour l’itération, il y a celles concernant la totalité du projet. Car le plus souvent il faut en passer par là. A moins que le projet fasse l’objet d’un financement récurrent ou qu’il soit en autonomie de financement (ce qui revient à peu près au même), les décideurs ont besoin de savoir quelles sommes devront être engagées sur le projet. C’est normal. Là encore, l’outil ad-hoc est l’estimation. Mais il y a quand même deux façons d’appréhender cela.

On peut faire ça à l’ancienne : on prend le backlog, on met des chiffres en face de chaque élément de backlog et c’est notre feuille de route. Bravo : notre enfermement dans des postulats vient d’atteindre un nouveau niveau. Nous voici prisonniers dans notre périmètre de réalisation.

Oh bien sûr on nous proposera « d’accueillir le changement » car on est dans un projet agile. Mais dès que le vent tournera, on verra resurgir le chiffrage initial. Dans ces conditions autant contrôler les changements à l’ancienne, via un « change control board ». De toute manière, de tout ceci émanent des effluves pas vraiment neuves. Et utiliser des cartes de planning poker pour cela n’y change rien !

L’autre méthode consiste à utiliser le chiffrage initial pour dimensionner une enveloppe de financement … puis oublier ce chiffrage pour concevoir et réaliser le produit de manière réellement émergente, en exploitant à chaque itération les connaissances acquises.

Découper, ça c’est votre affaire

Si les approches agiles et Scrum en particulier [7] promeuvent le découpage fin des fonctionnalités, elles ne mettent pas réellement en place de contraintes en ce sens, si ce n’est la taille des itérations ! Mon propos n’est donc qu’une fonctionnalité ne doive pas dépasser une itération (j’ai hélas vu des équipes mettre jusqu’à 3 itérations pour produire une « story » !), non ce découpage doit être fin, bien plus fin.

Mais ça ne vient pas tout seul.

En fait, sans la motivation appropriée, il est bien plus aisé au product owner de garder les fonctionnalités à grosse maille, souvent en arguant « qu’il faut tout, de toute façon ! ». Si c’est plus facile de découper pour l’équipe de réalisation, qu’ils le fassent ! Dans le registre lâche, j’ai même entendu parler de « détail d’implémentation » !

Je ne vais pas débattre ici des vertus du découpage des fonctionnalités pour les projets agiles. Mais la logique d’estimation de taille, si elle ne nuit pas ici, n’est pas non plus d’une grande aide.

Ma véritable estimation agile

Assez ronchonné sur les pratiques d’estimation ! Si mes récriminations doivent servir à quelque chose, c’est à comprendre ce que je veux obtenir d’une véritable pratique d’estimation « new style » !

• Pouvoir me focaliser sur la valeur lorsque l’on évalue la priorité des fonctionnalités. Et pour cela, il ne faut pas que la question de la taille vienne brouiller les cartes !
• Ne plus considérer le périmètre d’une application comme un ensemble de fonctionnalités à négocier, mais comme un (voir plusieurs objectifs) auxquels je subordonne des hypothèses qui sont autant d’options sur lesquelles je n’ai pas besoin de trancher à l’avance.
• Et au passage revisiter la notion d’engagement, abandonner les réestimations de reste à faire…

Ouvrons le bal !

Size-boxing

Nous avons évoqué précédemment la technique de priorisation par le ROI. Un grand classique : V/C ; Ainsi à valeur égale, la fonctionnalité la moins couteuse est la plus valable. Sauf que nous avons aussi souligné le travers consistant à sortir la valeur de l’équation. C’est un travers que je comprend aisément : ce n’est pas facile à appréhender la valeur, sauf dans certains contextes précis, et guère plus facile à mesurer quand ce n’est pas directement ou pas uniquement rattaché à une valeur faciale. Nous reviendrons sur cette question de la valeur un peu plus tard.

La solution la plus simple pour éviter le travers est de sortir « C » de l’équation. Il ne reste donc plus que la valeur qui du coup ne peut plus être ignorée. Un seul moyen : standardiser la taille, ou tout au moins travailler avec des tailles de fonctionnalités à réaliser assez semblables ! L’estimation de taille n’est d’ailleurs pas porteuse de valeur en elle-même [8], elle ne sert qu’à nous donner une idée de notre capacité afin de mettre notre processus sous contrôle.

Ainsi, de même que nous planifions avec une contrainte de temps (notre itération), mous devrions estimer avec une contrainte de taille. Nos interactions deviennent alors :

• Comment découper la fonctionnalité souhaité pour la faire tenir dans ma contrainte de taille ?
• Comment m’organiser en équipe afin d’accommoder cette contrainte de taille ?
• Quelles décisions de structuration et d’architecture dois-je prendre pour rendre cela possible ?

Subordonner le périmètre au « pourquoi »

Réfléchir à la question du périmètre produit en terme de liste de fonctionnalités et de ce qu’on y ajoute et/ou retranche n’est pas agile. Cela m’oblige à penser en terme de stock et m’en encombrer l’esprit. J’avais évoqué ce point lorsque j’avais parlé du backlog. A ce processus mental qui m’ancre dans mes anciennes idées, je préfère travailler à partir d’objectifs, évaluer et tester mes options relatives à ceux-cis, et itérer. Mais pour ce faire, nous devons nous libérer du mode de pensée qui lie ensemble le budget et la liste des fonctionnalités. Désolé Scrum, mais le « backlog estimé » en est justement l’illustration !

La valeur métier, c’est quoi ?

On le dit et on le repète : l’agile est fait pour se focaliser sur la valeur métier. C’est fort bien dit et en en a plein la bouche, mais c’est quand même rudement abstrait, surtout quand on ne peut pas directement lier le produit ou le projet avec une dimension financière.

Je sors un peu du cadre de mon propos, mais je ne pouvais pas non plus complètement éluder la question.

La valeur ce n’est pas (seulement) des considérations de ROI, il s’agit plutôt d’un cocktail qui intègre plusieurs ingrédients pour former un modèle de valeur [9]. Prenons celui-ci, par exemple :

Il s’agit en fait plutôt d’un métamodèle. Il vous invite à construire votre propre modèle, basé sur 3 dimensions :

• La finalité : elle n’est pas nécessairement purement financière. Il peut s’agir de donner une visibilité ou une image à l’entreprise, de se donner une avance technologique ou de tester un nouveau marché.
• Les considérations, qui sont les facteurs intrinsèques ou extrinsèques difficilement quantifiables mais influençant vos décisions.
• Les coûts et bénéfices du projet.

Chaque modèle de valeur est unique, il combine et priorise les éléments construits sur ces 3 axes.

Pour y arriver

Finalement, c’est probablement l’élément le plus facile, car nous avons déjà amené une bonne partie des éléments de réponse.

Tout d’abord, ne plus se servir du budget pour contraindre notre périmètre, mais partir du pourquoi et subordonner le périmètre à ce pourquoi à l’aide d’outils comme l’impact mapping [10].

Changer de logique d’estimation : plutôt que d’estimer la taille d’une fonctionnalité de périmètre donné, ré-orientons nos discussions pour estimer le périmètre des fonctionnalités afin de les faire tenir dans une taille donné, en gardant l’objectif dans notre ligne de mire ! C’est là un changement de paradigme fondamental, et il nécessite une façon de faire différente. L’occasion pour moi de développer cela un jour prochain, j’espère !

Changer de logique de processus. Kanban nous apprend à penser différemment: plutôt que de réfléchir en terme de stock, il nous conduit à penser en terme de « slot » de demandes disponibles qu’il suffit d’alimenter par ce qui est le plus prioritaire. Mais Kanban n’est pas une réponse suffisante quand on parle produit, car il focalise sur des questions de « capacité » et de SLA et non sur un objectif et la valeur, des aspects sur lesquels il est agnostique.

Doit-on arrêter d’estimer, comme peut le laisser croire (ou le laisser interpréter) le mouvement « no estimates » ?

Alors l’estimation, c’est mal ?

La réponse (aux deux questions précédentes) est : non ! Nous avons toujours quelque chose à estimer, mais il faut tourner cette estimation dans la bonne direction pour obtenir le résultat que nous voulons. Il faut estimer pour :

• Individualiser les hypothèses et les relier à notre modèle de valeur.
• Générer des idées et des options, fonctionnelles ou techniques.
• Etre en mesure d’avancer par petits pas pour obtenir du feedback rapidement et mettre notre processus de développement sous contrôle.
• Générer des interactions entre les acteurs du projet.

Nos estimations ne doivent pas nous conduire à :

• Se débarrasser du problème sur l’équipe de réalisation.
• Nous conduire à des marchandages entre les acteurs du projet
• Nous enfermer dans une réincarnation du cahier des charges que l’on ne peut plier qu’à force de négociations.

La route est longue…

Références

[1] : Software Estimation, Demystifying the Black Art – Steve McConnell – Microsoft press 2006 – ISBN: 0-7356-0535-1 ; p. 37

[2] : The Leprechauns of Software Engineering – Laurent Bossavit – Leanpub 2013 ; p. 13

[3] : Commitment – Olav Maassen, Chris Matts & Chris Geary – Hathaway te Brake Publications 2013 – ISBN : 978-90-820569-0-7

[4] : Leading Lean Software Development – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series – ISBN: 978 0 321 62070 5 ; p. 87

[5] : Lean Software Development, An agile toolkit – Mary Poppendieck & Tom Poppendieck – Addison Wesley / ASD series 2003 – ISBN: 0-321-15078-3 ; p. 38

[6] : Implementing Lean Software Development, From concept to cash – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series 2006 – ISBN : 0-321-43738-1 ; p. 160

[7] : Agile Project Management with Scrum – Ken Schwaber – Microsoft Press 2004- ISBN: 0-7356-1993-X ; p. 196

[8] : Scrumban, Essays on Kanban systems for lean software development – Corey Ladas – Modus Cooperandi Press 2008 – ISBN : 978 0578002149 ; p. 99

[9] : Stand Back and Deliver, Accelerating business agility – Pollyanna Pixton, Niel Nickolaisen, Todd Little & Kent McDonald – Addison Wesley 2009 – ISBN : 978 0 321 57288 2 ; p. 98

[10] : Impact Mapping : Making a big impact with software products and projects – Gojko Adzic – Provoking Thoughts Ltd. 2012 – ISBN : 978-0-9556836-4-0

Autres Ressources

• Où l’on parle d’engagement prématuré et de « set-based design »
• Mob programming et no estimates. On est un peu loin de notre sujet, mais bon…
• A propos de l’aspect réactionnaire du hashtag #noestimates
• Claude Aubry, sur l’engagement de Sprint
• Un autre point de vue sur le « no estimates »