Catégories
Méthodes agiles scrum

Les esti­ma­tions de petites tâches ne sont pas plus précises

Un des premiers mensonges qu’on vous livre trop souvent avec SCRUM c’est qu’on peut esti­mer des petites tâches avec bien plus de préci­sion que des grandes, et qu’en consé­quence on peut être assez fiable dans l’es­ti­ma­tion des une à trois semaines de chaque itéra­tion.

Foutaises !

Combien de temps faut-il pour mettre les blou­sons avant d’al­ler à l’école ? Mettons 30 secondes si on ne se presse pas. La réalité c’est que ça mettra plus souvent 5 minutes que 30 secondes, et ça c’est si on n’a pas besoin de se battre.

400% de marge d’er­reur ? Comment voulez-vous faire un plan­ning avec de telles esti­ma­tions. Pour­tant on est sur une tâche connue, répé­tée chaque jour. Seule solu­tion, on triche et on compte 2 minutes 30. Même ainsi on a une marge d’er­reur de 100%. Hallu­ci­nant !

Ce n’est pas un exemple choisi. J’ai le même problème pour termi­ner la tartine, pour boire le verre d’eau ou pour passer aux toilettes avant de partir, pour descendre dans la rue, pour faire le trajet, pour trou­ver le badge et passer le portail de l’école, pour montrer ma carte au vigile, pour les 10 mètres dans l’école au milieu des copains et autres parents d’élèves, pour le bisou de bonne jour­née avant de pouvoir repar­tir…

Ce n’est pas non plus la faute d’une mauvaise analo­gie. Esti­mer une petite tâche est juste impos­sible parce que le moindre aléa fait tout explo­ser.

Ajou­ter un lien sur une page ça prend 30 secon­des… sauf si on vous dit de chan­ger l’URL au dernier moment et qu’il faut faire deux fois le travail, sauf si c’est le seul lien à cet endroit et qu’il faut retou­cher les règles de style, sauf si le lien passe à la ligne en plein milieu et que visuel­le­ment ça ne le fait pas du tout sur ce compo­sant, sauf si l’es­pace pris fait glis­ser le bouton qui suit sous le clavier sur un smart­phone une fois le clavier déplié, sauf s’il faut partir à la chasse de la bonne URL parce que c’était « ça n’a pas d’im­pact, on donnera le lien au dernier moment », sauf si on se rend compte qu’il faut mutua­li­ser ce lien avec autre chose ailleurs dans l’ap­pli­ca­tion, sauf si ajou­ter un lien casse le test end-to-end et qu’il faut le réécrire pour faire passer le serveur d’in­té­gra­tion conti­nue au vert, sauf si… pour un simple foutu lien !


Et pour­tant, on n’est jamais en retard à l’école. Malgré les aléas infi­nis à chaque tâche, le projet « aller à l’école » prend 45 minutes à ±15 minutes. Pas plus.

Ce n’est même pas qu’es­ti­mer le projet dans son ensemble permet de lisser les risques de déra­pages, c’est que le temps que prend chaque tâche dépend de toutes les tâches précé­dentes et des options qu’il nous reste pour les suivantes.

S’il faut lutter pour termi­ner le crois­sant alors on active sérieu­se­ment la suite. Si les toilettes s’éter­nisent je prépare le blou­son et le bonnet pendant ce temps. S’il le faut on presse un peu le pas. À l’école, si on arrive dans les derniers, aucun parent d’élève ou cama­rade ne nous retient dans les dix derniers mètres et le bisou sera vite fait. Si vrai­ment on est super en retard on peut toujours sortir le vélo ou prendre le tram.


En réalité si SCRUM estime les fonc­tion­na­li­tés unitaires ce n’est pas pour s’en­ga­ger sur un résul­tat donné à l’avance, ni même pour mesu­rer si l’ité­ra­tion a été une réus­site ou un succès lors de la rétros­pec­tive. C’est unique­ment pour savoir où on va dans la boîte de temps qu’on s’est donnée. Rien de plus.

Quand on vous dit que ça permet d’être plus fiable, derrière se cache l’hydre du « on va trans­for­mer vos esti­ma­tions en enga­ge­ment » voire du « on va ajou­ter vos esti­ma­tions une à une et ça donnera la dead­line de fin de projet si rien ne change ».

Catégories
Équipes Méthodes agiles Objectifs

Story points

Points de complexité, points d’ef­fort, tailles de tshirt… J’ai vu des équipes travailler avec des comp­tages allant d’une mesure en heures de travail à des mesures au simple nombre de tickets.

Je n’ai pas trouvé de réelle corré­la­tion entre la réus­site des équipes et leur façon d’es­ti­mer, ou même avec l’exis­tence ou non d’es­ti­ma­tions.

Si je devais trou­ver un critère commun à la majo­rité des équipes que j’ai vu bien fonc­tion­ner, le voilà :

Les esti­ma­tions de tâches indi­vi­duelles sont réali­sées au lance­ment du travail. Elles ne sont pas utili­sées au-delà de la courte période de travail concer­née pour laquelle elles étaient prévues. Elles ne sont pas utili­sées en dehors de l’équipe ou de son fonc­tion­ne­ment interne.


Déci­der. On estime les epic, ces gros blocs qui recoupent géné­ra­le­ment plusieurs semaines voire plusieurs mois. Ces epic servent à faire des choix, déci­der de l’op­por­tu­nité de réali­ser, confron­ter les prio­ri­tés, savoir s’il est réaliste d’at­teindre l’objec­tif avant un événe­ment parti­cu­lier. Dans tous les cas on parle de stra­té­gie et de tactique.

Les points de complexité n’ont aucun sens à ce niveau. On a juste besoin d’un ordre de gran­deur. Les esti­ma­tions se font au doigt mouillé et c’est très bien comme ça. 30% de marge d’er­reur c’est presque de la surqua­lité.

Ces esti­ma­tions n’ont aucune valeur en dehors de la prise de déci­sion. Le péri­mètre n’est pas vrai­ment défini, la tech­nique en est à l’étude de faisa­bi­lité et aux pistes tech­niques crédibles ou non.


Réagir. Et puis à partir de là on passe éven­tuel­le­ment en réali­sa­tion. Mesu­rer l’avan­ce­ment permet de ne pas se perdre, d’iden­ti­fier les blocages, de se rendre compte quand on patauge. C’est ce qui permet éven­tuel­le­ment de dire « on a un problème, il faut chan­ger quelque chose » ou « l’ordre de gran­deur qui a mené à la déci­sion de réali­sa­tion se révèle faux, est-ce qu’on conti­nue ou pas ? ».

On peut mesu­rer en fonc­tion d’es­ti­ma­tions de travail ou en fonc­tion de ce qui est livré à la sortie. Les deux ont du sens et je vous invite à faire les deux. Côté scrum on parle de la burn-down qui trace le travail, limité à une itéra­tion ou à une date butoir, et la burn-up qui trace la valeur produite sur du plus long terme.

Ces esti­ma­tions ne servent qu’à ça, iden­ti­fier d’éven­tuels problèmes pour agir en fonc­tion. Elles ne servent pas à savoir si l’équipe travaille bien ou pas. Ce sont de sacré­ment mauvais indi­ca­teurs pour ça.


Et donc les problèmes arrivent quand on croise les deux.

Les esti­ma­tions et les plans ne sont pas faits pour mesu­rer le succès et le travail d’une équipe. Il sont faits pour déci­der et réagir. Rien de plus.

Un plan long terme ne se construit pas en jouant au puzzle à agen­cer plein de petits blocs ensemble pour les caser dans l’agenda. Ça ne fonc­tionne déjà pas pour les tâches de pure exécu­tion, parce que 18 tâches de 10 minutes ne prennent pas le même temps qu’une tâche de 180 minutes.

Ça fonc­tionne encore moins dès qu’il y a une acti­vité de réflexion, de créa­tion, ou simple­ment l’in­ven­tion de quelque chose qui n’existe pas. On ne connait pas tout à l’avance, le puzzle sera explosé avant d’avoir atteint le premier quart. C’est vrai autant d’un point de vue fonc­tion­nel que tech­nique.

Mais surtout, le plan est fait pour être changé. Mesu­rer la réalité par rapport au plan c’est dire que le chan­ge­ment et l’im­prévu doivent être vali­dés en amont, qu’ils sont anor­maux, qu’en que si la réalité ne corres­pond pas au plan c’est la réalité qui a tort et que le problème se situe donc au niveau de ceux qui suivent le plan.

Malheu­reu­se­ment essayer de tordre ou de contes­ter la réalité ne fonc­tionne que à ma connais­sance que dans les livres et les films de science-fiction (et encore : même là, en géné­ral, on a les problèmes qui nous sautent au visage dès qu’on essaie).

Par­fois il y a aussi des problèmes au niveau de ceux qui suivent le plan, mais savoir si la réalité est conforme au plan est tout sauf le bon indi­ca­teur pour ça.

Catégories
Méthodes agiles Vie professionnelle

Conti­nuous Deli­very: The Dirty Details

Il n’y a rien d’ex­cep­tion­nel­le­ment nouveau mais ça permet quand même de prou­ver certaines pratiques : Préfé­rer des déploie­ments en perma­nence plusieurs fois par jour plutôt que de faire un événe­ment une fois de temps en temps à date program­mée avec vrai proces­sus autour.

Catégories
Méthodes agiles

Product Mana­gers, Product Owners, and Scalable Models for Agile Product Teams (Cisco)

Le titre dit déjà tout. Peut être rien de révo­lu­tion­naire, mais quelques rappels et défi­ni­tions bien inté­res­santes.

Je refor­mule mais « les commer­ciaux ont pour rôle de faire tout ce qui est raison­nable ou dérai­son­nable pour boucler le gros deal à venir, dont les un ou deux trucs que que le produit n’a pas et qui sont spéci­fiques à ce pros­pect » parle sérieu­se­ment à mon expé­rience. C’est aussi une façon très claire d’ex­pliquer pourquoi les socié­tés qui veulent créer un produit ne doivent pas être diri­gés par les commer­ciaux, et doivent avoir des respon­sables produit indé­pen­dants.

Inté­res­sante aussi la distinc­tion entre product mana­ger et product owner. Pour tenter de la mettre en place depuis quelques mois, c’est parfois loin d’être évident.

Catégories
Méthodes agiles

How we do large scale retros­pec­tives

In late 2014 we had an oppor­tu­nity to run a program level retro for an inno­va­tion initia­tive that span­ned across 80–90 people in NYC and Stock­holm.  Instead of a large session, we opted to try some­thing bit different – and we found it to work better for these types of initia­tives.

Labs at Spotify

Et vous ? comment gérez-vous vos rétro ? Arri­vez-vous à rester construc­tifs à plus de dix ?

Catégories
Méthodes agiles

Micro­soft’s 16 Keys To Being Agile At Scale

Every six months there are scena­rio reviews. The group reviews progress and examine where they want to go next. That gene­rally means a recas­ting of the scena­rios. There are three ques­tions: what have we lear­ned over the last six months based on what we built? What do our custo­mers tell us? And what’s chan­ged in the market­place? It’s both plan­ning and lear­ning.

Every team has the autho­rity to make changes. If the team sees some­thing that was missed, they don’t have to ask permis­sion to make a change. They just keep the leader­ship team infor­med.

Faire confiance et respon­sa­bi­li­ser, étape bien plus impor­tante que toutes les ques­tions de post-it et autres arte­facts des méthodes agiles.

f the mana­ger yells at the team or moni­tors their burn-down chart, guess what the mana­ger gets? Perfect burn-down charts. So does the mana­ger want perfect burn-down charts or the right conver­sa­tion? In the end, it has to be the latter.

Parce que l’im­por­tant c’est de livrer de la valeur pour la société et ses utili­sa­teurs. C’est la seule métrique perti­nente, même si elle est diffi­cile à juger.

Si on juge par un tableau de bord, l’ef­fet obtenu sera l’amé­lio­ra­tion du tableau de bord, et pas forcé­ment le meilleur choix pour la société ou l’uti­li­sa­teur.

C’est d’ailleurs là aussi toute une ques­tion de respon­sa­bi­lité et de confiance aux équipes. La respon­sa­bi­li­sa­tion c’est consi­dé­rer que l’équipe peut casser l’in­di­ca­teur ou le mettre hors des clous, parce qu’elle juge que c’est le plus perti­nent, ou simple­ment parce qu’il y a eu une diffi­culté qui l’ex­plique.

— via Forbes, avec pas mal de bonnes choses à lire dans l’ar­ticle

Catégories
Méthodes agiles Vie professionnelle

Retro­mat – inspi­ra­tion & plans for (agile) retros­pec­tive

En panne sur les rétros­pec­tives ? Envie de redon­ner un peu de souffle et d’en­train ?

Florie m’a fait passer un lien vers Retro­mat, je vous recom­mande de jouer avec. Plein d’idées pour réflé­chir.

Plan­ning your next retros­pec­tive? Get star­ted with a random plan, tweak it, print it and share the URL. Or just browse around for new ideas!

Sur le même sujet : Fun retros­pec­tives Acti­vi­ties and ideas for making agile retros­pec­tives more enga­ging

Catégories
Développement informatique Méthodes agiles

One Product Team

One Product Team: We are not a sepa­rate group of desi­gners, gang of deve­lo­pers, bunch of testers, with a king product owner, who only meet each other when it is needed.

We sit toge­ther as a team. We talk and play every­day. And we all love what we are buil­ding.

— User expe­rience and design in BBC Play­lis­ter: how to be David Fincher

La sépa­ra­tion stricte des rôles, avec un process, un enchaî­ne­ment, une hiérar­chie, des bureaux distincts… comment avons-nous pu construire de telles habi­tudes ?

Catégories
Développement informatique Méthodes agiles

Prio­ri­sa­tion du back­log

Ce billet vient d’un désac­cord sur twit­ter sur les éléments qui permettent de prio­ri­ser un back­log dans un déve­lop­pe­ment agile.

On me propose de trier par valeur fonc­tion­nelle (je vais parler de valeur ajou­tée au produit, pour éviter de mélan­ger avec la complexité fonc­tion­nelle) mais cela ne me convient pas.

Toutes les histoires n’ont pas le même détail

Sur mon back­log j’ai de quoi remplir plusieurs sprints. Toutes les histoires n’ont pas le même niveau de détail. Détailler tout c’est passer un temps énorme à faire un travail qui risquera d’être remis en cause et qui délaiera inuti­le­ment le déve­lop­pe­ment. L’objec­tif n’est pas de faire un cahier des charges détaillé sur deux ans. Mon respon­sable produit fera ça au fur et à mesure. Ce qui est prio­ri­taire est détaillé et plus on s’en­fonce dans le back­log plus les histoires utili­sa­teurs sont « macro ».

Une « macro » histoire sera décou­pée en plusieurs petites. Logique­ment la valeur ajou­tée liée à cette macro histoire sera aussi divi­sée. Si vous suivez, il y a de bonnes chances pour que les macro histoires en milieu de sprint soient celles qui ont une colonne « valeur » avec les plus gros nombres. Les histoires à faire aujourd’­hui et demain seront bien décou­pées, et donc unitai­re­ment avec des petites valeurs ajou­tées.

Voilà mon premier argu­ment pour ne pas clas­ser que par la valeur ajou­tée : Ça revien­drait à mettre en premier les histoires les moins détaillées, puis les détailler (vu qu’elles sont prio­ri­taires), se rendre compte que du coup d’autres sortent avant, les redé­tailler, et ainsi de suite. En quelques itéra­tions on va finir par détailler trop préci­sé­ment un plan d’ac­tion pour plus d’un an, et faire un travail inutile tout en ayant mal prio­risé entre temps.

La prio­rité c’est sortir la plus grande valeur à chaque itéra­tion

Toutes les histoires n’ont pas le même niveau de détail, mais elles ne néces­sitent pas toujours le même effort non plus. Imagi­nons un site d’ac­tua­lité, avec une histoire « permettre de saisir un commen­taire » (c’était impos­sible jusqu’a­lors) et une histoire « affi­cher le titre séparé du corps de l’ar­ticle » (il était collé aupa­ra­vant).

Ajou­ter des commen­taires apporte bien plus de valeur qu’ajou­ter un espace entre le titre et le corps du texte, disons « 10 » pour le premier et « 2 » pour le second. Mais côté effort de déve­lop­pe­ment c’est la même chose : « 20 »pour le premier, et « 0,5 » pour le second.

Si je classe simple­ment par la valeur ajou­tée, je vais prio­ri­ser des histoires comme « saisir des commen­taires ». Pour­tant si je calcule j’au­rai eu plus de valeur ajou­tée à mon produit si j’avais prio­risé d’abord plusieurs histoires de type « sépa­rer le titre ».

Ma prio­rité c’est bien de livrer la plus grande valeur à la sortie de l’ité­ra­tion. La prio­rité est donc, logique­ment, plus dépen­dante du rapport valeur/effort que de la valeur elle-même. J’ai besoin d’avoir estimé mes histoires pour en connaître l’ef­fort et les prio­ri­ser. Un respon­sable produit qui prio­rise sans connaître l’ef­fort asso­cié à chaque histoire ne peut pas maxi­mi­ser la valeur de son produit, et c’est pour­tant tout l’objec­tif de la démarche.

Encore d’autres facteurs

Le ratio valeur/effort est pour moi un bon critère de tri pour la prio­ri­sa­tion. On ajoute après des contraintes fonc­tion­nelles comme les dead­line fonc­tion­nelles comme un contrat de parte­na­riat à implé­men­ter dans le mois.

Mais là aussi la tech­nique a son mot à dire. Nos histoires ont des dépen­dances tech­niques entre elles, et ça joue et doit jouer sur les prio­ri­tés. De même tout déve­lop­peur sait bien que parfois faire deux tâches ensemble permet de gagner un temps certain. Il y a des prio­ri­tés d’op­por­tu­nité à faire : d’un coup je peux faire à moindre coup une fonc­tion­na­lité qui est norma­le­ment plus bas dans le back­log.

Parfois j’y gagne à court terme (parce que le niveau d’ef­fort dimi­nue telle­ment qu’elle devient bien prio­ri­taire). Parfois j’y perd un peu à court terme mais je gagne bien en valeur à moyen terme puisqu’au final j’ai bien dimi­nué l’ef­fort et donc permis de faire une histoire de plus. Tout est un équi­libre entre le gain en terme d’ef­fort et la valeur de l’his­toire à reprio­ri­ser.

Catégories
Méthodes agiles

Perplexité, complexité, vélo­cité … une autre vue

J’ai lu « Perplexité, complexité, vélo­cité » sur le blog d’OCTO. L’ar­ticle est bien tourné et on sort complè­te­ment convaincu. Mon problème c’est que quelques heures après j’ai commencé à avoir des doutes et plus les jours avancent plus mes doutes se trans­forment en avis contraire. Je vous encou­rage à lire d’abord le billet d’OCTO, le mien n’aura de sens qu’en réponse.

À quoi sert la vélo­cité ?

À quoi sert la vélo­cité ?

1.     Esti­mer ce qui sera réalisé ou non dans le sprint

2.     Mesu­rer la produc­ti­vité de l’équipe

3.     Mesu­rer le réalisé pour le projet, le produit

Ma diver­gence avec l’ar­ticle source vient d’un constat simple : Nous n’uti­li­sons pas cet indi­ca­teur dans le même objec­tif. Lui l’uti­lise pour mesu­rer la produc­ti­vité, moi pour amélio­rer les esti­ma­tions.

Amélio­rer les esti­ma­tions

Amélio­rer les esti­ma­tions c’est faire en sorte de mieux évaluer ce qui sera livré dans chaque sprint et aider à la prio­ri­sa­tion. Bref, gérer le projet.

Pour amélio­rer nos esti­ma­tions on tente de se baser sur les tâches simi­laires précé­dentes et on en réuti­lise l’es­ti­ma­tion sans tenir compte de la produc­ti­vité de l’équipe. On utilise pour cela une unité virtuelle qui nous détache des jours/hommes : le point. Réali­ser une esti­ma­tion ainsi est de plus en plus simple, rapide et fiable.

Pour prendre en compte les évolu­tions de produc­ti­vité (équipe plus effi­cace ou dette tech­nique gran­dis­sante) c’est le nombre de points réali­sable dans un sprint qu’on fait varier. Afin de ne pas sortir le dé pour évaluer ce nombre de points, on se base sur ce qui a été réalisé dans les quelques sprints passés et on tente de rester sur une courbe la plus stable possible.

Nos réfé­rences d’es­ti­ma­tion sont stables, nos esti­ma­tions se fiabi­lisent avec le temps. Le nombre magique de points qu’on peut mettre dans un sprint, c’est pour moi ce qu’est la vélo­cité de l’équipe.

En prenant en compte la tech­nique

Si on calcule en points et pas en heures ou en jours, ce n’est pas parce qu’on compte en complexité fonc­tionne, c’est pour s’au­to­ri­ser à faire varier la somme totale plutôt que chaque esti­ma­tion.

Il ne faut pas perdre de vue que notre objec­tif reste bien d’éva­luer une charge de déve­lop­pe­ment. Il faut donc tenir compte dans nos esti­ma­tions de tout ce qui est néces­saire à évaluer le temps de déve­lop­pe­ment et livrer la fonc­tion­na­lité : Ça va des besoins fonc­tion­nels à la complexité tech­nique en passant par les contraintes orga­ni­sa­tion­nelles spéci­fiques.

Si je ne prends en compte que la complexité fonc­tion­nelle, l’es­ti­ma­tion n’aura plus aucun lien avec le temps de déve­lop­pe­ment. Pour savoir ce qui tient ou pas dans le sprint, on en vien­dra à faire une esti­ma­tion globale, au jugé, sans réfé­rences simi­laires : tout l’in­verse de l’objec­tif.

Outil privé versus indi­ca­teur public

À mon humble avis l’er­reur de l’ar­ticle n’est pas seule­ment de faire de la vélo­cité une mesure de produc­ti­vité, c’est en plus de l’avoir commu­niquée à l’ex­té­rieur de l’équipe.

Du coup, forcé­ment, la vélo­cité devient un enjeu poli­tique. L’équipe, son mana­ger, son coach commencent à avoir inté­rêt à amélio­rer l’in­di­ca­teur au lieu de se concen­trer sur ce qui devrait être leur seul objec­tif : appor­ter de la valeur au produit.

Que la vélo­cité augmente, dimi­nue, c’est quelque chose propre à l’équipe. S’il faut un indi­ca­teur de produc­ti­vité et de pertur­ba­tion, il faut publier la seule chose impor­tante : la progres­sion de la valeur du produit (si ça ressemble au para­graphe précé­dent, ce n’est pas une coïn­ci­dence).

Cette vélo­cité doit être prise pour ce qu’elle est : un outil d’es­ti­ma­tion, de plani­fi­ca­tion et de prio­ri­sa­tion. Comme tous les outils, il a voca­tion à être utilisé en interne, par l’équipe, et nulle part ailleurs.

Et la complexité fonc­tion­nelle ?

Mon second problème est là : Selon moi la complexité fonc­tion­nelle n’in­dique rien de valable. Ce n’est pas une mesure de ce que coûte la fonc­tion­na­lité, ce n’est pas une mesure de ce qu’ap­porte la fonc­tion­na­lité, et inci­dem­ment ce n’est pas une mesure de l’im­pli­ca­tion ou de la produc­ti­vité de l’équipe.

Tout au plus la complexité fonc­tion­nelle permet de faire une première esti­ma­tion des histoires utili­sa­teurs qui ne sont pas prévues pour tout de suite ou dont on ne connaît pas la complexité tech­nique.