Le Planning Poker — à abolir pour le bien du projet et de l’équipe ?

Vous connaissez tous les “Sprint planning”, célèbre “cérémonie” de Scrum ?

Ces réunions qui durent assez longtemps où le Product Owner présente les priorités des développements à assurer pour le sprint qui vient.

Lors de cette réunion, il est demandé à l’équipe de développement d’estimer les efforts à fournir pour chacune des différentes tâches.

Pour cela, le Scrum Master présente son fameux jeu, le Planning Poker, connu de la plupart des équipes se revendiquant “agiles”.

Ce n’est autre qu’un jeu de cartes dont les valeurs sont les suivantes : 
0, ½, 1, 2, 3, 5, 10, 20, 50, 100.

Ces valeurs sont censées quantifier l’effort à fournir pour une tâche donnée
Plus la valeur est élevée, plus la tâche demandera de l’effort et donc souvent plus de temps.

Comment le Planning Poker se déroule-t-il ?

Le Product Owner lit la description de la fonctionnalité à haute voix et l’équipe doit estimer l’effort à fournir pour la réaliser.

Chaque développeur est doté d’un jeu de cartes contenant toutes les valeurs ci-dessus.


“Choisissez vos carteesss … à 3 vous les retournez, 1, 2 et 3 !”

Bruno a choisi 2.
Stéphane a choisi 5.
Julien a choisi 13.

“Bah !! On dirait que vous n’êtes pas d’accord, expliquez-vous, il faut trouver un terrain d’entente !”

On rejoue :

“Bruno a choisi 5”.
“Stéphane a choisi 5”.
“Julien a choisi 5”.

Bruno a augmenté son chiffrage et Julien lui l’a rabaissé. 
Ils ont coupé la poire en deux sans réel débat approfondi car…la réunion doit continuer et il y a encore beaucoup de tâches à estimer.

Mais pourquoi un tel écart de chiffrage entre les développeurs ?!

Hypothèse numéro 1 :

Julien est moins expérimenté que les autres.
La tâche à accomplir lui parait beaucoup plus ardue.
Fatalement, un 13 lui semblait censé.

Il suffit de 2 ou 3 séances de Planning Poker pour que Julien se dise alors : 
“Bon…je passe pour un âne à chaque fois, ils vont tous penser que je suis le tracteur de l’équipe; je vais arrêter d’être honnête et je vais tirer des plus petites cartes; tant pis; c’est mon égo qui me guide”.

Dénouement assuré : Julien ne sera plus honnête à l’avenir dans ses estimations !

Hypothèse numéro 2 :

Julien est bien plus expérimenté et perfectionniste que les autres, il voit le problème soulevé par la tâche d’une manière BEAUCOUP plus complète et profonde !
Il a pensé à toutes les validations à implémenter pour le formulaire; à tous les “wrong paths”; tous les aspects de sécurité subtils etc; le côté responsive du site Web à assurer etc... 
Quant aux autres ils n’ont eu qu’une vision simpliste, remplie de failles, et donc peu perfectionniste de l’histoire.

Dénouement assuré : Julien aura de longues discussions/débats avec les autres développeurs après la cérémonie (car oui, y’a pas le temps pour débattre profondément en Sprint Planning) pour leur expliquer qu’ils visualisent à chaque fois la moitié du problème.

Bonjour le froid dans l’équipe !

À l’avenir, devenus moins confiants, Stéphane et Bruno rallongeront leur chiffrage, même si dans les faits ils n’ont pas la capacité d’évaluer réellement la tâche qui les attend car trop peu expérimentés voire ignorants de plein de notions techniques.

Julien quant à lui songera, toujours par égo, à abaisser ses chiffrages pour ne pas paraître exagérant auprès des autres acteurs du projet.

Hypothèse numéro 3 :

Julien chiffre large pour ne pas ressentir de pression lors du sprint. 
Il aime prendre son temps pour travailler, il n’a pas envie de transpirer; après tout il n’est pas si bien payé que cela selon lui.

Dénouement assuré : Les autres développeurs le détecteront rapidement et se diront :

“Bon bah je vois pas pourquoi l’on se donnerait corps et âme pour aller vite pour au final n’avoir aucune reconnaissance particulière ?! On va faire comme Julien, on va prendre notre temps et donc chiffrer large ! Et puis personne lui ‘gueule’ dessus; donc bon”.

Hypothèse numéro 4 :

Bruno chiffre très bas (2 !) car il souhaite passer pour un employé ultra efficace quantitativement et non qualitativement, et compte tenu de l’état du logiciel à son arrivée, il désire absorber les tâches à la vitesse de l’éclair sans réel soin poussé car de toute façon “Le logiciel est déjà crade en l’état !”. 
Il a compris que les managers n’étaient pas si exigeants que cela qualitativement parlant et que 10 ou 20 bugs de plus ce n’est pas ce qui va ruiner le business.

Dénouement assuré : Il sera bel et bien considéré comme ultra efficace par ses managers qui n’y verront que du feu AU DEBUT; mais sera en froid avec le reste de son équipe; ce dernier voulant être fier d’une bonne copie rendue.

Bruno et éventuellement Stéphane, par égo, chiffreront leurs tâches et finiront par craquer en mettant leur perfectionnisme de côté. 
“Soit on reste et on fait comme Julien, soit on quitte la mission mais ce sera dur de payer le loyer en attendant de trouver autre chose; on fait comme Julien allez !”

Résultat : La niveau de qualité du produit sera à la baisse; pour finalement engendrer une complexité accidentelle et donc une dette technique gigantesque dans un futur très proche; menant le projet au cimetière le plus proche.


Mais…toutes les hypothèses évoquées n’ont pas de dénouement positifs et les estimations semblent alors tout à fait non-fiables, comment faire alors ?

Michael Azerhad, de WealCome, conseille d’abolir strictement les séances de Planning Poker. 
Pas d’anéantir les estimations hein ? (quoique … ce sera l’objet d’un autre article, mais c’est un next level).
Mais bien d’anéantir cette pratique qui consiste à estimer “pris au dépourvu” sans réflexion profonde en amont
.

What ?!

Je cite Michael Azerhad :


Ce qui suit, je l’ai expérimenté plusieurs fois avec gros succès :

Pour estimer des tâches à venir, je préfère que les développeurs de l’équipe et UNIQUEMENT EUX se réunissent tous dans une salle, HORS séance de Sprint Planning et en AMONT de celui-ci. 
L’équipe aura déjà eu auparavant la connaissance du “gourou” de l’équipe, en quelque sorte la personne qui voit les choses bien plus en profondeur que les autres à l’heure actuelle.

Cherchez bien, il y a TOUJOURS une ou deux personnes dans l’équipe qui surprend (relativement parlant) par ses raisonnements et sa vision à la fois macro et micro des problèmes. 
Celui-ci (ou ces 2) prend/prennent la parole et présente sur un tableau blanc TOUTES les tâches à accomplir pour assurer une fonctionnalité dans son ENSEMBLE de manière perfectionniste et cohérente.

Les autres écoutent, et à tout moment peuvent l’interrompre s’ils ont une interrogation, une incompréhension, un avis personnel, voire même une critique !

Dans ce genre de réunions entre développeurs, on a le TEMPS de parler/débattre technique.

Ça peut durer même la journée s’il le faut; il faut en profiter !

Peu à peu, au fil des sprints, les “juniors” ou “seniors” moins expérimentés auront affiné la vision micro des problèmes grâce aux différentes attentions portées sur le “gourou” (énorme avantage de cette pratique !) et pourront alors à leur tour est plus autonome quant à leurs estimations.

Dans ce cas-ci, ils pourront estimer désormais dans leur coin en détaillant les tâches, qu’ils transmettent par mail (ou Slack pour les plus modernes) au gourou de l’équipe, souvent le Tech Lead, en vue d’avoir un retour et une potentielle validation.

Ainsi, plus besoin de jeux de cartes car le Tech Lead étudiera ces propositions d’estimations et réunira à nouveau les développeurs pour qu’ils estiment TOUS ENSEMBLE le chiffrage qui sera ACCEPTABLE, MOYEN, COHÉRENT ET CONFORTABLE (sans trop l’être ;)) pour toute l’équipe !

Lors du Sprint Planning, qui se verra donc insolemment raccourci, l’équipe saura déjà quel nombre annoncer dans la bonne humeur générale; aucune secousse !

Il y règnera (vécu) une bien meilleure ambiance dans l’équipe ;)

C’est le rôle du GOUROU => celui de montrer la direction à suivre pour que Padawan devienne un jour Jedi !


Et vous, qu’en pensez-vous de cette solution ? ;)