Blog entries

  • De retour du raid agile

    2015/03/17 by Sylvain Thenault
    https://www.logilab.org/file/288474?vid=download

    J'ai eu la semaine dernière la chance de participer au raid agile organisé par Pablo et Claudio. Je dis bien une chance car, de mon point de vue, cette formation atypique donne vraiment l'occasion de passer quelques jours loin du quotidienn dans un cadre idyllique et une ambiance sympathique, à réfléchir aux fondements des méthodes agiles. En plus d'y (re)découvrir un tas d'outils et de jeux agiles, c'est l'occasion d'échanger avec tous les participants et de remettre en cause ses pratiques. Bref, une bonne remise à zéro des compteurs. Je ne vous révélerais pas plus l'emploi du temps minuté-mais-aéré des trois jours (vous en saurez plus sur le site), je ne saurais que vous recommander de sauter sur l'occasion de partiper à une prochaine édition du raid !

    Ceci étant dit, revenons-en à l'objet principal de ce billet : ce que j'ai ramené dans ma petite tête pour améliorer nos pratiques à Logilab. Ou en tout cas celle que j'essaie de mettre en place avec mon équipe à Toulouse.

    Une de mes principales problématiques est la suivante : comment adapter une méthode comme Scrum ou un outil comme le kanban dans le cadre d'une petite société de service, où nous avons majoritairement des petits projets, plusieurs en parallèle, développés par une à deux personnes maximum ? La littérature sur le sujet applique systématiquement (à ma connaissance) la méthode à des équipes de développement "produit" avec des phases souvent gérées par des personnes différentes (développeurs, testeurs, intégrateurs, etc.). Ça fait un moment que je tâtonne sur le sujet, d'une manière parfois satisfaisante, parfois frustrante, mais certainement améliorable. Sans prétendre avoir répondu à toutes mes interrogations, une réflexion de Claude m'a donné envie d'améliorer un point en particulier : travailler en équipe, plutôt qu'être une somme d'individus dans un même espace. Le principal changement à conduire consistera donc à faire travailler tous les membres de l'équipe sur tous les projets. Il y aura bien sûr un coût non-négligeable dans la mise en place de chacun sur chaque projet, mais j'espère que cela sera contrebalancé par :

    • la montée en compétence de l'ensemble de l'équipe ("essaimage")
    • moins de spécialisation individuelle, plus de souplesse dans la gestion des projets
    • un renforcement de l'esprit d'équipe

    Pour moi, ça vaut donc le coup de tenter ! Et le compagnon de ce changement sera un autre point qui me pose souvent question : le découpage des besoins du client en user stories (voir features ou epics) et tâches, leur relation avec le kanban qu'on essaie de mettre en place (principalement pour visualiser les tâches de chacun jusqu'ici) et notre extranet de gestion de projet. Jusqu'ici, nous dupliquions plus ou moins l'information, sans vraiment faire ressortir la notion de tâche autrement que dans les discussions informelles. Pour maintenir un rapport coût de gestion / besoin de collaboration et d'indicateurs, on va maintenant essayer de maintenir les histoires dans l'extranet, avec leur estimation, les discussions avec le client et autres (dépendance, relation aux features, etc.), tout en ayant sur le kanban les tâches qui en découlent. Ceci devrait notamment permettre de mieux échanger sur les implémentations des différentes histoires en amont, voire de permettre à plusieurs personnes de travailler sur la même histoire. Et ainsi de rendre le kanban plus au centre de notre gestion quotidienne en diminuant sa granularité.

    Ces deux points sont les gros morceaux qu'il va falloir digérer dans les prochains mois. Parmi les autres points abordés ou évoqués pendant la formation et ramenés en stock, il y a :

    • faire un delegation board avec l'équipe à Toulouse et peut-être aussi à l'échelle de Logilab entre les équipes de direction et de développement, voire au sein de l'équipe de direction ;
    • ne pas oublier de faire fixer l'heure sur l'horloge de Cohn à nos clients qui jouent le jeu de l'agilité (ils ne seront jamais assez nombreux) ;
    • faire plus de rétrospectives, sans hésiter à en essayer différentes formes ;
    • à l'occasion, réessayer un impact mapping, l'exercice le plus délicat que nous ayons abordé ;
    • rappeler que si on fait des journées "compactes" à Toulouse, il ne faut pas oublier de maintenir un rythme soutenable. Voir acheter un canapé ou un siège confortable pour les amateurs de power nap (merci Pierre-Jean dont la pratique décomplexée est rafraichissante !) ;
    • enfin creuser les core protocols et le business value game dès que possible, voire réfléchir au #noSlides pour nos formations techniques.

    Voilà, y a encore d'autres restes parmi les outils et idées discutés, mais je pense avoir cité ici l'essentiel et ça promet déja des impacts non négligeables. J'accueillerais avec plaisir vos remarques ou idées sur les points ci-dessus. Et avec un peu de chance j'aurais même le courage de faire un billet pour raconter ces différentes expériences ! En tout cas, encore un grand merci à Pablo et Claudio ainsi qu'à tous les participants de ce raid du changement.


  • Châtaignes, Saucisson et Méthodes agiles... on était au Raid Agile #4 !

    2016/02/15 by Marla Da Silva

    Adrien, David, Katia et moi avons participé au 4ème raid agile organisé par Pablo Pernot et Claude Aubry dans les Cévennes.

    https://www.logilab.org/file/4386083?vid=download

    Je partage l'avis de Sylvain Thénault, lorsqu'il a dit ici il y a quelques mois "j'ai eu la chance de participer au raid agile organisé par Pablo et Claudio", car à mon avis, c'est vraiment une chance de pouvoir se retrouver dans un gîte des Cévennes pour une formation agile originale pendant trois jours et trois nuits. Pendant cette formation, on arrête tout et on partage ses expériences, on joue, on randonne ensemble, et surtout on apprend les nouvelles pratiques du management, de l’agilité organisationnelle et de la gestion de produit. On parle, bien sûr, de participer à des ateliers d'impact mapping, de story mapping, de faire des échanges sur Scrum, Kanban et d'approfondir ses connaissances sur la culture agile.

    Malgré un côté un peu "monomaniaque" (on est isolé au milieu de nulle part, on fait des randonnées, on arrive en haut de la montagne et on ne parle que des méthodes agiles), à aucun moment on ne parle de vie personnelle, ce qui permet de vite se couper du monde extérieur et s'impliquer dans les jeux. Les profils distincts des participants (grands groupes, PME et indépendants) a permis d'échanger et de se rendre compte que les problèmes ne sont pas si différents et qu'on peut trouver un moyen d'adapter l'agilité pour les résoudre.

    Je n'ai pas pu m'empêcher de réfléchir à ce qu'on pourrait mettre en œuvre pour améliorer les pratiques agiles déjà instaurées au sein de Logilab. Ce qui est intéressant, c'est que je me suis toujours dit que les méthodes agiles ne s'appliquaient qu'aux développeurs, et désormais j'ai vu qu'on peut appliquer cette nouvelle façon de travailler dans tous les domaines d'activité dont celui de la communication.

    Je pense surtout au chef de projet qui doit mener son projet à terme tout en respectant les délais et surtout le budget dédié. Et pour atteindre son objectif, le chef de projet doit penser au contenu, au calendrier, au budget mais aussi à la satisfaction du client (et j'ajouterais même "à sa fidélisation"). À travers les méthodes classiques, on se voit confier le projet, on le démarre et on avance... selon une ligne droite : on valide l'étape précédente avant de passer à la suivante. Sauf qu'il arrive (et très souvent) qu'on ne valide pas l'étape précédente et que, par manque de temps ou de budget, on fonce vers l'étape suivante. Il en résulte un très grand stress et s'il faut revenir en arrière pour corriger un problème, c'est toujours plus coûteux.

    https://www.logilab.org/file/4386092?vid=download

    Dans les méthodes agiles, on nous propose de découper le travail en plusieurs itérations, qu'on gère en tant que "mini-projets" définis avec le client. Ensuite on identifiera — toujours avec le client — les différentes fonctionnalités et leur priorité. Résultat : le client pourra clarifier ses attentes et ses exigences pendant que le projet avance et il se sentira rassuré d'avoir une meilleure visibilité sur le projet (objectifs à court terme livrés régulièrement). L'amélioration se fait en continu, la qualité reste tout le temps contrôlée et les risques sont identifiés au plus tôt. Tout au long du projet, l'équipe reste motivée car ses objectifs sont toujours proches et sont régulièrement atteints (à chaque fin d'itération). Et s'il arrive qu'il n'y ait plus de budget, le projet peut s'arrêter sereinement et le client n'est pas surpris car il a suivi l'évolution du projet.

    Dans les méthodes agiles on se focalise sur l'objectif, on découpe le temps, on fixe des échéances, on propose des livraisons fréquentes, on suggère des aménagements en permanence, on communique avec ses collègues, son équipe et le client (on parle d'un échange étroit entre toutes les parties prenantes, une réflexion constante,) et surtout... on accepte le changement.

    https://www.logilab.org/file/4386097?vid=download

    Par exemple, nous avons appris la méthode Scrum grâce à un exercice consistant à faire ensemble un puzzle de 500 pièces. 3 équipes de 3 personnes ont été formées. À cette occasion nous avons dû :

    • déterminer les exigences du client (son objectif : le puzzle monté),
    • identifier les priorités (quelles étaient les parties que le client souhaitait voir réalisées en premier et pourquoi),

    Des mêlées ont été organisées à la fin des sprints de réalisation afin de contrôler l'avancement du projet. Ceci nous a permis de faire un rapport qualitatif et quantitatif du projet. Le client nous a fait part de son mécontentement, et nous avons pu expliquer que le produit ne pourrait pas être livré dans le délai souhaité. Le client a donc pu comprendre nos contraintes et nous avons pu trouver ensemble une solution satisfaisante.

    Ce jeu m'a permis de comprendre scrum et m'a montré son efficacité. Je comprends mieux pourquoi chez Logilab nous appliquons les méthodes agiles à nos développements et tous nos projets.

    https://www.logilab.org/file/4386104?vid=download

    L'ensemble des outils évoqués tout au long du raid s'appuie sur du matériel issu du mouvement agile. Le contenu est dense, on enchaîne les jeux à grande vitesse, et malgré (ou grâce à) des visions souvent opposées, Pablo et Claude ont su nous immerger dans l’agilité.

    Je ne saurais trop vous recommander de sauter sur l'occasion et de participer à une prochaine édition du raid !