Carnet de notes

Catégorie : Méthodes agiles

  • Arrê­tons avec les frame­works agiles

    Jetez moi SCRUM, Shape-up et les autres, et encore plus leurs versions dites « at-scale » type SAFe.

    Je ne comprends même pas comment on en est arrivé là alors que le mani­feste agile met en avant «  Les indi­vi­dus et leurs inter­ac­tions, de préfé­rence aux proces­sus et aux outils ».

    Prétendre cadrer les indi­vi­dus et les inter­ac­tions via des proces­sus et des outils métho­do­lo­giques est un contre-sens total de ce qu’on a appris depuis le mani­feste.

    Quand on me demande ma méthode de prédi­lec­tion je parle de Kanban, parce que l’im­plé­men­ta­tion dans le logi­ciel revient juste à limi­ter le flux et donner une prio­rité à ce qui est déjà en cours, avec une grande liberté d’im­plé­men­ta­tion. S’il s’agis­sait de cher­cher une implé­men­ta­tion « comme dans la litté­ra­ture », je raye­rais d’un trait et range­rai Kanban avec les autres.

    Appliquer des outils et des proces­sus tout faits ça rassure quand on n’a pas confiance dans les indi­vi­dus et leurs inter­ac­tions.

    Le fond c’est la défiance, souvent du top mana­ge­ment, même si parfois elle se diffuse jusqu’aux équipes elles-mêmes à force de leur poser des exigences contra­dic­toires.

    L’idée c’est souvent que si les résul­tats ne sont pas ceux espé­rés c’est que les équipes travaillent mal, alors on va leur expliquer comment il faut travailler en impo­sant une recette sans cher­cher à appro­fon­dir les problèmes eux-mêmes.

    Rien que le présup­posé me semble toxique.

    Ne vous mépre­nez pas. Je trouve formi­dable que Base­camp forma­lise la façon dont ils fonc­tionnent. Ce n’est pas une critique de leur fonc­tion­ne­ment. Il y a plein de choses à penser dans la lecture de Shape-up.

    Le trans­po­ser tel quel avec des rituels, par contre, c’est proba­ble­ment une mauvaise idée. Trans­po­ser quoi que ce soit tel quel est proba­ble­ment une mauvaise idée d’ailleurs. Le cargo-cult est bien trop présent dans l’uni­vers logi­ciel, et encore plus dans l’uni­vers star­tup.

    Chaque équipe a ses besoins, des aspi­ra­tions, ses contraintes, ses indi­vi­dus. Croire que ce qui fonc­tionne à côté fonc­tion­nera chez nous en le reco­piant c’est se trom­per de prio­rité entre les indi­vi­dus et les proces­sus. C’est d’au­tant plus vrai qu’en géné­ral on en applique les arte­facts visibles mais pas la philo­so­phie sous-jacente.

    Je ne suis même pas convaincu que ce soit un bon point de départ pour ensuite itérer. Les rituels ont tendance à ne pas bouger, voire à s’ac­cu­mu­ler, surtout qu’ils appar­tiennent à « la méthode ». S’il faut commen­cer c’est proba­ble­ment par SLAP.

    Tout n’est pas à jeter. Il y a plein d’idées inté­res­santes à reprendre à droite et à gauche. Mon problème c’est la reprise d’un cadre complet comme si ça allait résoudre les problèmes.

    Dans mes boites à outils, en fonc­tion des besoins, j’au­rais tendance à conseiller les points suivants :

    • Des rétros­pec­tives régu­lières, à date fixe
    • Des itéra­tions de durée rela­ti­ve­ment fixe
    • Des points de synchro internes fréquents voire quoti­diens
    • Des démos aux utili­sa­teurs et parties prenantes
    • Une notion d’ap­pé­tit pour les sujets qu’on veut livrer
    • Une esti­ma­tion d’ordre de gran­deur de l’ef­fort pour la prio­ri­sa­tion

    Bref, un kanban avec des cycles qui permettent de régu­liè­re­ment sortir la tête du guidon, prendre du recul, voir ce qu’on veut chan­ger dans notre fonc­tion­ne­ment, déci­der quelle direc­tion on veut prendre pour la suite, et de vrais échanges amonts pour expli­ci­ter la complexité et l’ap­pé­tit pour les diffé­rents items.

    Le reste s’ajoute avec grande prudence. Sauf besoin spéci­fique j’au­rais tendance à décon­seiller les items suivant :

    • Les enga­ge­ments de livrai­son, hors besoin absolu (on ne déca­lera pas Noël)
    • Les esti­ma­tions autres que des ordres de gran­deur
    • Les back­logs (oui oui, vous avez bien lu)
    • Avoir plus d’un objec­tif par itéra­tion
    • Avoir déjà étudié la solu­tion avant de commen­cer
    • Tenter d’ap­pliquer ce que d’autres équipes font dans d’autres contextes au sein d’autres cultures

  • 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 ».

  • 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.

  • 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.

  • 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.

  • 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 ?

  • 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

  • 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

  • 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 ?

  • 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.