Retour d’Expérience : Deux jours « Agile » à Vincennes

DevOps & Agilité, Event Mercredi 22 juin 2016 Pas de commentaire

20160617_111247

J’étais les jeudi et vendredi 16 et 17 juin à Agile France, à Vincennes, pour découvrir, apprendre et partager avec toute la communauté Agile, dans la bonne humeur et la bienveillance.
Voici quelques moments choisis de ces deux jours, pour ceux qui n’ont pas eu la chance de participer à cet événement.

Jeudi 9h40 – « Dashing deux en un, pour un dashboard étincelant » – Nathaniel Richan
Nathaniel nous explique qu’il est Product Owner depuis maintenant 2 ans sur un projet et, malgré le fait qu’il portait les outils électroniques de management visuel en horreur, il s’est laissé convaincre par Dashing.
Dashing est un outil permettant de construire facilement, moyennant un peu de code Ruby et un peu de coffescript, de jolis dashboards.
Voici quelques indicateurs qu’il a pu mettre en place sur le projet :
• Indicateur équipe : récupération des informations de Team Mood que chaque membre remplit le soir vers 17h, afin d’afficher un tableau d’Emoticons de l’équipe.
• Indicateur de production : nombre de mise en production, frise chronologique des releases.
• Indicateur sur :
o les tickets qui ne bougent plus depuis un certain temps
o WIP
o les tickets done
• Indicateurs métier
Nathaniel a ensuite effectué un live coding afin de nous montrer avec quelle facilité nous pouvons construire un panneau du Dashboard, même lorsqu’on est novice en Ruby. Dashing n’est plus maintenu mais possède une grande communauté avec de nombreux widgets disponibles.
La démo est disponible ici.

 

20160616_095057

 

Jeudi 11h00 – « Libérez vos talents » – par Eric Siber
La présentation avait mal commencé : l’ordinateur d’Éric n’a pas voulu démarrer. J’hésitais, comme les autres participants, à me rabattre au plus vite sur une autre session mais Éric assuma courageusement et décida de faire sa présentation de mémoire. Un joli jeu d’équilibriste sans filet et, avec le recul, je peux dire qu’il s’est bien défendu.
Éric a collecté, pendant plusieurs semaines et auprès de plusieurs entreprises, leurs méthodes pour découvrir, recruter et retenir les talents.
Mais, avant de passer aux témoignages, intéressons-nous d’abord à ce qui peut entraver l’épanouissement de ces talents. Deux causes peuvent expliquer le désengagement émotionnel des talents dans nos sociétés : la hiérarchie pyramidale qui ne laisse pas une place suffisante à l’autonomie et à la créativité, mais aussi le système scolaire qui ne responsabilise pas assez les enfants et qui ne propose pas assez de travaux collectifs.
Tout le monde est potentiellement un talent, et les motivations extrinsèques comme le salaire ne peuvent suffire à l’épanouissement de ces derniers. Il faut rechercher des solutions ailleurs : mise en place de réseaux sociaux afin de promouvoir le partage, encouragement des employés à prendre des initiatives (comme aller aux conférences Agile France), management one to one où le manager se place à l’écoute du collaborateur, mentorat, entreprenariat, notion de tributs…

 

Jeudi 14h30 – Après midi consacrée à un forum ouvert

Pour ma part, je choisis de participer à des conversations autour du Process COM et autour du DEVOPS.
Process COM et coaching Agile
Cette analyse repose sur le postulat que le comportement d’une personne peut être définit selon une mosaïque se basant sur 6 profils de personnalités distincts. Ces profils vont ensuite déterminer les besoins psychologiques de la personne, les canaux de communication à privilégier et la réaction de cette personne face à une situation de stress. Chaque personne possède un profil de base, et les événements de sa vie peuvent lui faire acquérir de nouveaux profils. Les profils s’empilent à la façon d’une pyramide et viennent moduler le comportement de la personne.
Ce travail d’analyse peut être mis en place lors de conflits entre collaborateurs ou en cas de problèmes de communication Manager/employé. Petite mise en garde, il est déconseillé d’analyser les personnes qui vous entourent pour communiquer en utilisant leurs canaux de communication. Il faut privilégier l’utilisation de cet outil sur soi même, pour ensuite indiquer aux personnes qui vous entourent comment communiquer avec vous.
Cette discussion était vraiment enrichissante ! Je recommande d’ailleurs le livre « Comment leur dire… La Process communication » de Gérard Collignon pour en savoir plus.

Voici également quelques liens :
• Process communication (Wikipédia)
• Qu’est ce que la process communication ? (Institut Repère)

 

DEVOPS et agilité

Nous avons ensuite échangé autour du DEVOPS pour savoir ce que cela représentait à nos yeux, ce que cela impliquait dans l’organisation, afin de déterminer le lien entre DEVOPS et Agilité.

 

Vendredi 9h30 – « DDD : et si on reprenait l’histoire par le bon bout ? Tout simplement. » – par Thomas Pierrain et Jérémie Grodziski
Deuxième journée de présentation et un nouveau départ vers le DDD. J’ai bien lu « Domain Driven Design vite fait » qui résume en français le livre d’Eric Evans sur le DDD mais, étant donné ce que j’ai retenu, une grosse piqûre de rappel ne me fera pas de mal. Je suis curieux de découvrir comment les orateurs vont aborder le sujet. La présentation commence par une petite citation d’Alberto Brandolini :
« It’s developer understanding, not your knowledge that becomes software »
Soit en français : « C’est la compréhension du développeur et non votre connaissance qui part en production ». D’où la nécessité que le développeur et la personne en situation de besoin se comprennent au mieux. Le DDD peut aider à unifier la connaissance métier. D’ailleurs, pour les orateurs, le DDD doit nous aider et même nous inciter à maximiser la valeur métier.
La présentation abordera les patterns du DDD en suivant 3 niveaux d’abstraction : celui du développeur, celui de l’équipe et celui du SI.
Pour ce qui concerne le niveau développeur, commençons pour nous persuader des bienfaits du pattern « VALUE TYPE », par refactorer un code qui « smell » (pas bien codé) ; pas de « magic number », de la duplication de code, de la technique mixée avec du code métier… Cet exemple de panier de produits était vraiment parfait pour illustrer le problème et rien qu’en définissant le montant du panier comme un « VALUE TYPE » et quelques constantes bien nommées, on gagne déjà un peu en lisibilité. Le « VALUE TYPE » est immuable, riche en logique domaine et ne peut être comparé qu’en prenant en compte tous ces attributs. En effet ; 10$ n’est pas égal à 10€. La vidéo est disponible en anglais sur le lien suivant et je vous invite à la découvrir ici

 

Vendredi 10h30 – « Comment obtenir des standups qui marchent ? » – par Florence Chabanois

Oh non, encore le stand up… Beaucoup d’entre nous traînent les pieds pour y aller, mais pas Florence ! Elle a trouvé le moyen de motiver les équipes et de faire de cette réunion un moment où chaque membre de l’équipe va pouvoir booster son niveau d’énergie, organiser sa journée et se fixer des objectifs.
Alors, pour commencer, comment repérer une situation qui dégénère ? D’après Florence, les personnes ont tendance à regarder leurs pieds ou le PO, préparent ce qu’ils vont dire et n’écoutent pas ou peu les autres membres de l’équipe. Pas mal de techniques existent pour tirer le meilleur parti de ce moment :
• changer l’ordre d’intervention
• ne pas évoquer ce qu’on a fait la veille pour se concentrer sur la planification de la journée et les problèmes rencontrés
• aborder les problèmes en premier, car ceux-ci peuvent changer notre planification de la journée
• noter visuellement les retards…
Florence nous a donné toute une boîte à outils. Une dernière question émane de l’assemblée : est-ce que le PO doit participer activement au standup ? Selon Florence, lorsque le PO participe au standup, cela force les développeurs à adapter leur discours pour une meilleure compréhension, voir à cacher des problèmes. Pour moi, cela dépend de la maturité et du niveau de collaboration entre le PO et les développeurs.

 

Vendredi 11h30 – « Le contrat Agile, ce n’est pas si simple » – par Franck Beulé

J’avais hâte de participer à cette session car elle s’inscrit vraiment dans l’ensemble des problématiques que je risque de rencontrer prochainement. Le contrat Agile, d’après Franck doit être rédigé selon 3 parties :
• on définit une enveloppe de points contrats et où on va répartir ces points sur le périmètre découpé en fonctionnalités et en épiques.
• La première phase de calibrage : sprint 0 et les 3 premiers sprints, on va avoir une obligation de moyens
• La deuxième phase opérationnelle : après le sprint 3, l’équipe va avoir une obligation de résultats.
Je ne rentrerai pas davantage dans la description car vous pouvez trouver tous les slides de Franck ici [http://blog.beule.fr/] mais, si je dois retenir un enseignement, je dirai que la chose la plus importante dans le contrat Agile, c’est le lien de CONFIANCE entre le client et son fournisseur. Après, il faut juste agir en bonne intelligence.

 

Vendredi 14h – « Mon Produit est super génial, revue de vision avec des Lego » – par Yannick Ameur et Nathaniel Richand

Je suis arrivé trop tard pour être acteur de cet atelier, c’est donc en tant que spectateur que je vais vous en parler. Yannick et Nathaniel ont divisé le groupe en deux équipes de 4 personnes. Ils ont eu pour première tâche de construire en Lego, un Persona pour assister à la conférence Agile idéale. Les joueurs expliquent alors à l’équipe pourquoi ils ont choisi ou construit leur persona de cette manière. La deuxième étape de l’atelier consiste à construire la conférence agile idéale et à faire participer le persona créé précédemment. Alors que les deux premiers travaux étaient individuels, le suivant consiste à construire une histoire de manière collective…
A première vue, rien ne ressemble plus à des Lego qu’un jeu de Lego. A première vue, en effet…mais après avoir parlé avec Nathaniel, on apprend que les joueurs doivent respecter certaines contraintes de communication, avec l’impossibilité de toucher les pièces d’un autre joueur. En imposant ces contraintes, les participants construisent une vision collective du produit sans qu’aucun d’eux ne soit obligé de renoncer à son idée initiale. L’atelier doit se dérouler sur une journée et, contrairement à l’aspect simpliste du jeu, le fait de jouer avec des Lego pour ce travail est très régulé ; il existe des licences déposées, des certifications… Tout le monde ne peut pas prétendre animer un atelier Lego serious play.
C’était très intéressant de pouvoir effectuer un parallèle entre le cadrage agile dit « classique » et cette façon de construire une vision commune du produit.

20160617_145957

 

Vendredi 16h15 – « Menace sur l’équipe projet » – par Adrien Piquot et David Vaidis

Quelle est la différence entre une dinde et un homme ? C’est ce que propose de nous démontrer ici les deux orateurs. Après une courte introduction sur le comportement social de la dinde, les présentateurs nous ont prouvé que le contexte social conditionne nos comportements. La psychologie sociale, qui existe depuis 1895, est la science qui étudie le comportement et les interactions entre les individus. C’est avec son aide qu’Adrien et David nous ont dévoilé divers comportements humains parmi lesquels :
• Le biais d’optimisme : plus la cible est éloignée dans le temps, plus les personnes sont optimistes
• Le biais de partage de l’information : les personnes ont tendance à partager les informations connues du groupe en gardant pour elles celles qui ne sont connues que d’elle-même.
• L’effet de gel de la décision : les personnes auront beaucoup de mal à remettre en cause une décision prise collectivement.
• Le piège abscons/ piège de l’engagement : les personnes ont du mal à revenir sur une décision qu’elles ont prise ; exemple d’une personne à qui on annonce progressivement des frais sur une voiture. Si la personne avait connu tous les frais dès le début, elle aurait refusé de payer. Mais étant donné qu’elle a déjà engagé des frais, celle-ci va aller au bout des dépenses.
• …
• Biais de contraste, d’assimilation, stéréotypes : classification d’une personne à un groupe et assimilation des comportements du groupe à celle-ci…
Au fur et à mesure qu’Adrien et David nous amusent et nous surprennent avec ces différents comportements, ils agrémentent l’apprentissage avec des situations de la vie quotidienne. Merci messieurs pour cette superbe collaboration.

Et voilà, c’est déjà la clôture de Agile France… Vivement l’année prochaine !

Eric Lannemajou, chef de projet agilité chez Axones

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn