Tag :Agile France

Un coup de pouce pour Agile France et Mix-IT ?

Agile France et Mix-IT ont ouvert leurs appels à orateurs depuis quelques semaines déjà. Et comme pour Devoxx France, nous souhaitons voir plus de femmes dans ce genre de conférences et nous vous proposons de vous aider à soumettre des sujets.

Mix-IT

Mix-IT est une grande conférence qui a lieu tous les ans au mois d’avril à Lyon sur l’agilité, l’écosystème Java et les innovations IT. Cette année, ils optent pour un format de conférence plus participatifs où les sessions proposées seront soit des présentations en mode conférence de 55 min (questions incluses), soit des ateliers dont la durée est à proposer. Une bonne occasion de proposer des jeux ou encore des hands-on avec ce nouveau format ! Quelques femmes sont déjà à l’honneur cette année, mais vous aussi, vous pouvez en faire partie !

L’appel à orateurs est ouverte jusqu’au 28 Février inclus et pour soumettre un sujet il vous suffit de créer un compte sur le site de Mix-IT et de proposer votre session.

Agile France

logo-agile-france-2013 Agile France en est à sa 8ème édition cette année ! Cette année les organisateurs souhaitent cibler les praticiens avancés et permettre aux participants d’apprendre en dehors des sentiers battus. Mais qu’est-ce qu’un praticien avancé ? Un praticien avancé agile, c’est par exemple :

  • le développeur agile familier des pratiques agiles comme le TDD, le Pair Programming … qui souhaite toujours s’améliorer et partager/apprendre de nouvelles pratiques,
  • le product owner qui souhaite partager/apprendre la façon de maximiser la valeur de son produit,
  • et le coach agile qui veut partager/apprendre de nouvelles façon d’aider à l’adoption des pratiques.

L’appel à orateurs est ouverte jusqu’au 2 Mars et ça se passe ici.

L’une de ces conférences (voire même les deux) vous intéresse mais vous hésitez à proposer des sujets. On vous propose, comme pour ceux de Devoxx France, de les roder avec nous en petit groupe (soirée “privée”) que ce soit sur Paris, sur Lyon ou via Skype pour celles qui habitent dans une autre ville. On s’organisera en fonction de chacune pour que tout le monde puisse passer au moins une fois. Un bon moyen pour s’entrainer et progresser pour être prête le jour J !

Nous pouvons aussi vous conseiller dans la rédaction de votre réponse au Call For Paper!

Et une fois n’est pas coutume, ces soirées sont réservées aux femmes.

Si vous avez des questions, n’hésitez pas à nous les poser en commentaires ou via mail duchessfr ou encore sur notre Google Groups.

Agile France 2010 – Jour #2

La fatigue, je vous dis ...

La fatigue, je vous dis …

Florence Chabanois et moi même Claude Falguière étions là aussi pour le deuxième jour. La fatigue s’accumule mais on ne va pas rater plein de bonnes choses pour autant.

Un plus par rapport à la veille, on maîtrise maintenant le trajet et il n’a pas été nécessaire de se lever aussi tôt.

Le deuxième jour la keynote était consacrée à Esther Derby qui nous a parlé a parlé de confiance dans l’équipe et des moyens de l’acquérir et la conserver dans “Self-help for Self-organizing Teams”.

Un exemple simple d’action que l’on peut avoir dans un projet en n’acceptant pas certains comportements impolis à montré qu’on est tous acteurs des relations dans l’équipe.

Jeu de Rôle Scrum par Yannick Ameur

Une présentation toujours très animée et pédagogique.

Jeu de rôle SCRUM : le Product Backlog

Jeu de rôle SCRUM : le Product Backlog

6 participants constituent une équipe projet pour construire un château.

Les participants ont un rôle dans le projet décrit sur une carte et comme dans tout vrai projet certains joueront un rôle non contributif, voire négatif.

Et bien sûr le client ne sait pas ce qu’il veut non plus. Une fois le château construit, il veut finalement autre chose.

Le but de l’expérience est de montrer moment l’équipe arrive à répondre à la problématique malgré tous ces écueils en mode cascade et en mode Agile.

Les photos de cette session sont en fil rouge dans l’article.

Jeu de rôle SCRUM : construction du château

Jeu de rôle SCRUM : construction du château

XP/TDD avec des technologies “legacy” par Pascal Ognibene

Claude Falguière

Pascal Ognibene qui travaille depuis longtemps dans le monde des télécoms, nous a fait un retour d’expérience sur la mise en place de TDD dans des environnements C++ ou sur des logiciels spécifiques.

C’est une bataille difficile qui doit se préparer avec soin et il faut savoir que cela coûtera cher car la mise en place demande encore beaucoup de scripting spécifique.

La difficulté vient du retard dans le portage des outils du monde Java dans le monde du C++, d’obstacles à surmonter liés à la technologie (par exemple, les éditions de liens en C++ qui peuvent ralentir considérable le rythme) , mais surtout la dette technique particulière de l’application qui fait que ses composants ne sont souvent pas testables isolément.

Jeu de rôle SCRUM : c'est l'heure de l'inauguration sous les confettis

Jeu de rôle SCRUM : c'est l'heure de l'inauguration sous les confettis

Consensus workshop, par Thi Lan Huong LE

Florence Chabanois

L’objectif de la session était de trouver ensemble “Comment améliorer les relations entre producteurs et utilisateurs” (ou quelque chose comme ça).

La méthode a vraiment le mérite de générer beaucoup d’idées (des très bonnes) mais le consensus est difficilement atteignable quand les participants sont nombreux, en dépit des efforts de l’animatrice.

Le principe était déjà de partir de propositions individuelles, d’élargir à un groupe plus restreints de 3 personnes, puis au 30-40 participants.

  • Chacun cherche 10 propositions sur sa feuille
  • Fait une sélection dessus (en les triant je crois)
  • Dans un groupe de 3 personnes, on se partage les idées et on doit en dégager 7.
  • Chaque idée est à écrire sur une feuille A4, bien visiblement
  • On ramasse 3 idées préférées de tous les groupes sur le mur (un tissu magique permettait de retenir les feuilles, sans colle, et ça tenait bien !!!)
  • Le groupe entier essaie des les trier par ressemblance sur des colonnes séparées. C’est une phase très très longue et le consensus me parait vraiment peu atteignable ici.
  • Un ramassage est effectué avec les 4 idées restantes de chaque groupe, si elles ne sont pas encore apparu dans le tableau.
  • Le groupe essaie de les rattacher aux colonnes existantes, sinon d’en créer d’autres.
  • Le groupe tente ensuite de donner des noms à chaque colonne. Par exemple : “favoriser la communication”.
  • A la fin, il y a autant d’axes que de colonnes pour résoudre le problème. Les papiers en dessous sont des moyens de le faire.
  • Dans le plan d’actions : il vaut mieux commencer par les solutions les plus impactantes et/ou les plus simples à mettre en oeuvre.

J’ai apprécié le souci de consensus, même si je n’ai pas le sentiment qu’il ait été atteint. Par contre, c’était réellement excellent comme exercice de brainstorming.

Jeu de rôle SCRUM : le plus beau château ... celui que le client veut

Jeu de rôle SCRUM : le plus beau château … celui que le client veut

Fin de cette seconde journée

On repart bien fatiguées mais avec plein d’idées en tête.

Merci aux organisateurs d’Agile France 2010 pour leur travail

  • Sébastien Douche
  • Yannick Ameur
  • Agata Sobik
  • Pascal Pratmarty
  • Thibault Bouchet
  • Jonathan Scher

Nous laissons le mot de la fin au canard qui est venu assister à XP/TDD avec des technologies “legacy”.

Je laisse le mot de la fin au canard qui est venu assister à XP/TDD avec des technologies "legacy"

Coin !

A suivre, en 2011 !

Début de l’article : Jour #1

Les textes sont de Florence Chabanois et Claude Falguière. Les photos sont de Claude Falguière.

Agile France 2010 – Jour #1

Florence Chabanois et moi même Claude Falguière étions à Agile France 2010 au début du mois. Avec pas mal de retard un retour à quatre mains sur Agile France 2010 et les sessions qui nous ont intéressées.

Le programme aussi a un peu souffert

Agile France 2010conférence agile sur les méthodes agiles” se déroulait cette année au Chalet de la Port Jaune, un très beau site près du château de Vincennes.  Plus de 300 personnes se sont déplacées, un record pour cette conférence.

Suite au changement de nom de XPDays à Agile France l’audience a un peu changé et mêle  les XP guys de longue date et des curieux venus découvrir le monde Agile et SCRUM. Cela explique probablement aussi la présence de bien plus de filles que l’année dernière.

L’ambiance était décontractée, les échanges nombreux favorisés par le buffet présent en permanence, la qualité des repas, les pauses suffisamment longues pour aller faire un tour au buffet, et des activités d’animation pendant ces pauses.

Beaucoup de contenu car les sessions se sont déroulées sur 6 salles (voir 7 par moment). De nombreux sujets sur Scrum, TDD, la gestion de configuration logicielle et toutes les techniques de l’agilité. Quelques sujets un peu plus techniques et pas mal de présentations sur la communication pour s’ouvrir l’esprit. A commencer les deux keynotes.

David Gageot et Eric Lefèvre présentent les règles du jeu

Si vous voulez voir le programme vous le lirez mieux .

La coder Academy

Agile France 2010 a introduit une compétition  en 3 manches entre développeurs lors de pauses déjeuner et avant le diner : la Coder Academy.

Le but était principalement de montrer des applications réelles de TDD sous la forme de Coder Dojo. Si le terme Coder Dojo ne vous dis rien vous pouvez vous référer à la présentation d’Emmanuel Gaillot qui était là aussi en tant que membre du jury.

Les sujets donnés au hasard étaient des Kata en 7mn soit TDD à partir de rien, soit Refactoring en TDD d’un code de son choix.

A l’exception de Christophe Thibaut et Jonathan Perret qui ont présenté un kata en Haskell, tout le monde a fait du Java, avec des variantes comme Play! ou Groovy.

L'équipe Christophe Thibaut et Jonathan Perret, les plus haskell (et les plus forts aussi ;-))

La finale s’est déroulée en figure imposée : implémenter  la liste des n premiers nombres premiers en TDD à partir de rien en Ruby en randori (chaque équipe passe à tour de rôle pour 5mn sur le même code).

Le véritable enjeu était le temps. 7mn c’est très, très court quand on est de l’autre côté du clavier, et probablement très, très long pour les gens qui nous voient peiner ;-) . Mais certains kata on été très réussis.

Si après ça vous êtes tentés vous pouvez rejoindre plusieurs des participants de cette Coder Academy au coding dojo qui est organisé tous les lundi soir  à Paris. Il y en a aussi deux autres, mais on verra ça une autre fois.

Les photos de la Coder Academy  illustrent ce post en fil rouge.

L'équipe, Eric Mignot et Fabien Bezagu, les plus speeds

La keynote de Bruno Sbille

Claude Falguière et Florence Chabanois

La keynote de Bruno Sbille “PNL et Agile: les yeux, les oreilles et les sensations” nous a présenté rapidement comment utiliser les méthodes de la PNL pour améliorer notre communication dans un projet Agile.

La PNL ou Programmation Neuro Linguistique est un ensemble de méthodes déduites de l’observation de gens efficaces.

Le premier point traité par Bruno Sbille est qu’il faut savoir interagir avec les auditifs, les visuels et les tactiles/kinesthésiques sur des canaux différents sinon ils ne comprennent tout simplement pas.

Comment les reconnaître ? Les types de verbes utilisés sont un critère. Les auditifs utiliseront plutôt des descriptions verbales assez longues, les visuels des dessins, les kinesthésiques des interactions physiques et des ambiances. Les différents systèmes de représentation sont traités dans la PNL sous le terme VAKOG si vous voulez aller plus loin.

L'équipe Nicolas Martignole et Olivier Catteau, les plus beaux chapeaux ...

La seconde partie de la keynote de Bruno Sbille a commencé par des scénettes de la vie quotidienne (qui n’a pas oublié de reboucher le dentifrice un jour). Dès qu’il y a plusieurs personnes dans une équipe elles peuvent créer un triangle dramatique et se livrer à des jeux psychologiques plus ou moins conscients. Le triangle comporte 3 rôles : le persécuteur, la victime, le sauveur, et le jeu peut commencer à 2 joueurs en configuration victime/persécuteur ou victime/sauveur.

Chaque type de rôle trouve un intérêt à le jouer, y compris la victime, qui peut d’ailleurs être la source du triangle en attirant aussi bien les persécuteurs en puissance que les sauveurs.

Ces jeux sont nuisibles pour l’humeur de l’équipe, car ils créent des conflits ou des dépendances excessives. Paradoxalement, le sauveur aussi est problématique car il peut en arriver à prendre en charge le travail de tout le monde.

Vu qu’il y a probablement quelques sauveurs par ici, je vous délivre le message : Quand sauver ?

  • est ce qu’on me le demande ?
  • est ce que j’ai le temps ?
  • est ce que j’en ai les compétences ?
  • est qu’il y aura un échange ?

et si jamais le sauveur prend la décision de sauver il faut  rendre la “victime” active en lui demandant de prendre en charge 50% du travail.

Keynote intéressante mêlant habillement le visuel, l’auditif et le kinesthésique et beaucoup de matière à réflexion sur nos agissements.

L'équipe Claude Falguiere et Fabrice Bouteiller, les plus mixtes

Au delà de l’équipe, l’entreprise agile, par François Bachmann

Florence Chabanois

Les points importants : auto-organisation, auto-organisation, auto-organisation et pour que ce soit possible, il faut fournir un conteneur (C), un cadre dans lequel l’équipe puisse s’exprimer. Une équipe à qui on dicte la conduite en disant “va à droite, à gauche, tout droit” fonctionnera forcément moins bien qu’une autonome. La dissonnance (D) et les erreurs doit également être acceptée pour que la créativité soit possible. Les échanges (E) doivent abonder : plus de communication et moins de docs. C’est le CDE.

François Bachmann aborde également le problème de la gestion des ressources humaines : comment “récompenser” l’agilité, et sur quels critères? Par analogie, comment évaluer les performances d’un footballeur ? Si l’on mesure les mètres parcourus, d’une part le but final de gagner des matchs n’est pas forcément atteint, d’autre pas le footballeur risque de ne faire que cela, sans s’intéresser au reste. J’ai aussi envie de dire que le système de récompense peut être pervers dans le sens s’il faut systématiquement “payer” les pots cassés quand l’on se trompe. On risque de se renvoyer la patate chaude pendant que personne ne prend de responsabilités.

La résistance à l’agilité peut avoir plusieurs causes :

  • la perte de contrôle liée à la promotion de l’auto-organisation, même si le contrôle n’était qu’une illusion
  • l’équipe se considère déjà agile et il n’y a pas de problèmes, tout va bien. En fait les problèmes sont dissimulés au lieu d’être montrés au grand jour.
  • certaines personnes aiment suivre des règles
  • la motivation baisse
  • “c’était mieux avant” (pour l’équipe, pas pour le client…)
  • l’expert ne trouve plus sa place

Pas toujours facile d'être juge, des discussions intenses et pendant ce temps les candidats attendent le verdict

Quelles directions à suivre :

A faire

  • Former les équipiers, sur de la technique mais pas seulement. Promouvoir des façons de pensées et des approches différentes.
  • Avoir un véritable projet pilole qui apporte de la valeur pour le client

A éviter

  • Changer les noms et garder les mêmes rôles. Le “chef de projet” est maintenant un “scrum master” et il fait exactement la même chose qu’auparavant…
  • Conduire un changement “big bang” : “A partir d’aujourd’hui, tout le monde ici est agile !”. L’adaptation doit se faire graduellement.

Et pour finir, cela sent mauvais si :

  • La décision de passer à l’agilité est un ordre du management
  • On veut des résultats immédiats. Il faut le temps qu’il faut, comme pour apprendre le vélo.
  • Il y a un acharnement sur les termes agiles : “backlog”, “scrum”.. ces mots font peur ! Il vaut mieux se concentrer sur les idées plutôt que les étiquettes.
  • Scrum est vu comme une solution magique. Scrum donne des pistes, un cadre mais il faudra forcément plus pour guérir.
  • Les bonnes pratiques sont aveuglément suivies. Il faut aussi comprendre le pourquoi, voir si elles s’intègrent dans notre organisation et les faire évoluer après. François évoque à ce sujet un livre sur les 40 entreprises qui marchent, dont la plupart avaient coulés dix années après. Chaque organisation est unique et il n’y a pas de solution universelle.

Le Lean Office : améliorer la performance administrative, par Michel Baldellon

Florence Chabanois

Michel Baldellon montre par les chiffres qu’un “petit” problème peut, à force d’être répété, devenir insidieusement le coeur du travail d’une entreprise. L’exemple ressemblait à cela : considérant qu’il faut une unité de temps pour faire un rapport, et que l’imprimante en abime 1 sur 10 (on se dit que c’est tolérable).

Les juges enthousiastes après le kata de Christophe Thibaut et Jonathan Perret

  • 10 rapports faux => 10 unités passés à les faire
  • 90 rapports bons => 90 unités passés à les faire

Pour détecter que le rapport est en erreur et le corriger, il faut 10 fois plus de temps.

Sur les 100 initiaux, voici les couts :

  • 10 rapports faux : 110 (10 + 100)
  • 90 rapports bons : 90

On passe au final plus de temps sur la partie boguée qui semblait minime que sur le coeur du métier.

Trois points sont soulignés !

  • Management visuel. Utiliser des couleurs pour donner du sens. L’exemple cité est celui d’un bureau désordonné comparé à une étagere avec classeurs post-ités
  • Identification du gaspillage. L’exemple évoqué est celui du bac rouge dans une usine, qui recueille les produits défectueux. La ligne de production est continue (“flow continu”), simplement les problèmes sont mis en valeurs et isolés pour pouvoir être traités plus tard.
  • Méthode de résolution de problème. Une fois qu’une cause est identifiée, elle est affichée. A chaque fois qu’on la rencontre, on trace un trait. On voit ainsi facilement que la cause 1 est survenue 30 fois alors que la cause 2 est apparue une seule fois. On peut ainsi objectivement traiter la plus importante. Il rappelle aussi que traiter un problème tout de suite permet de ne pas avoir de documentation à écrire et à maintenir et nous épargne de la resynchronisation.

Voici d’autres points soulevés, en vrac :

  • quand on veut obtenir quelque chose, plutot que simplement le demander, montrer en quoi il y gagne (ex : on ne peut pas vous payer car il manque le numéro de facture).
  • certains services aiment le gaspillage, cela rend la “vie moins monotone”, cela rassure car on sait le traiter. La cause profonde d’un problème n’est pas intéressant, on connait le contournement. La démarche “Qualité totale” n’est pas universelle, et dans certains services moins que d’autres.
  • notion de file unique. Avoir des files spécialisées favorise les situations où certaines sont pleines et d’autres vides. Plutôt qu’avoir des personnes dédiées, il vaut mieux des gens polyvalents. La présence de guichets simples permet aussi d’accéler le flux (exemple des caisses pour panier de moins de 10 articles dans les supermarchés).

Un article sur le Lean Office est en ligne sur le site de Michel Baldellon.

Benoit Gantaume : Introduction au processus de pensée visuelle / Sortez vos crayons

Claude Falguière

Cette série de sessions s’appuie sur la méthode Visual Thinking que Dan Roam a exposé dans son livre Back of the Napkin (site web très dynamique et la présentation des principes de la méthode dans le livre blanc est très percutante)

La finale, les juges commentent le randori; avis consultatif, c'est le public qui jugera

La présentation a duré 4h (1h le matin et 3h l’après midi). D’abord quelques explications des concepts puis un atelier pour expérimenter ces concepts.

Le visual thinking est une technique d’utilisation du dessin pour résoudre des problèmes et exposer une idée.

L’idée a germé quand Dan Roam a gribouillé un dessin sur le dos d’un nappe pour expliquer une idée. Puis il a complété ses recherches avec des éléments provenant d’études sur le fonctionnement du cerveau.

Le but n’est pas de faire des jolis dessins mais des dessins qui donnent du sens et avec des moyens très simple de type papier/crayon.

La technique exposée permet d’organiser la démarche qui permet de collecter les informations, les organiser, compléter ces informations en imaginant les éléments qui manquent puis présenter le résultat obtenu.

Elle est guidée par deux axes :

  • le type de questions que l’on peut poser : qui/quoi, quand, où, combien, comment, pourquoi ou les 6W (toutes ces question comportent un W en anglais)
  • la façon d’aborder ces questions résumé par SQV1D qui force notre imagination a entrer en jeu pour examiner le problème sous plusieurs angles avec des oppositions.

SCRUM dans l'exercice "Compare". Avec quoi à votre avis ?

L’auteur propose en ensuite des modes de représentation adaptés à chaque type de question selon l’angle sous lequel on veut les traiter.

Le speaker Benoît Gantaume a présenté la méthode et des exemples d’utilisation. Il a animé plusieurs ateliers portant sur les différentes techniques. Le plus long en fin d’après midi sur SCRUM en images a donné quelques jolies oeuvres qui ont été mises en ligne  par Benoît Gantaume.

Je reproduit le dernier qui vient de mon équipe car il a mené à un délire collectif sur le client envoyant ses specs par dessus les creneaux de la tour qui restera un souvenir mémorable de cette session d’Agile France.

Une présentation très intéressante mais qui aurait gagné a être un peu plus rapide.

Fin de la première journée

Le public, c'est pour eux qu'on était là ;-)

Journée bien remplie. Pour celles et ceux qui sont restés au repas c’est l’heure d’aller diner et d’avoir des discussions passionnantes avec les autres participants et les speakers.

Suite de l’article : Jour #2

Les textes sont de Florence Chabanois et Claude Falguière. Les photos sont d’Eric Lefèvre et Claude Falguière.

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer