dimanche 11 novembre 2012

Agile Grenoble et Agile Innovation 2012



Cette semaine, j'ai passé 2 superbes journées à Grenoble, pour Agile Grenoble 2012 et Agile Innovation 2012. En voici quelques éléments de retour.




Ce que j’ai aimé


  • Des rencontres avec plein de personnes que je connais et qui me connaissent, et des discussions très intéressantes, merci !
  • Des rencontres et échanges avec des personnes que je ne connaissais pas, les nouvelles rencontres sont évidemment indispensable et riches
  • La session d'Alexis Monville et Bruno Sbille (voir ci-dessous)
  • Une découverte plus concrète et plus précise du Kanban grâce au « Challenge Kanban » de Laurent Morisseau
  • Les pauses entre les sessions d’Agile Grenoble permettant de souffler et discuter
  • Les sessions libres d’Agile Innovation, permettant de papillonner (même si finalement, je ne l’ai presque pas fait)
  • Présenter (enfin ?) une session à Agile Grenoble : merci à tous ceux que j’ai pu rencontrer depuis 1 an qui m’ont donné la confiance et la motivation de le faire !
  • La logistique, la localisation de conf près de la gare et du centre, l'accueil et le staff

Des choses notées ou retenues


Sessions Agile Grenoble :


  • Donner du sens à la transition agile / Anticiper et rencontrer les managers / Pour les coachs et managers : expérimenter et permettre l’échec / Itération 0 pour bien apprendre la méthode / Management visuel compréhensibles et à jour [Monville-Sbille]
  • Dans la chaîne d’automatisation des tests, ajouter un vérification sur le langage et éventuellement les conventions d’écritures, notamment pour les langages interprétés (PHP, JavaScript, CSS, etc ….) [Ch. Ney]
  • Le "bocal à con" (même si le terme est peut-être mal choisi) de Sylvaine Pascual dont j’avais déjà entendu parler mais à creuser. Et bien sûr la remarque très intéressante : si mes bocaux sont très remplis, se poser des questions, qui est le con ? [L. Sarrazin]
  • Il est bon de choisir un gestionnaire de sources qui a une interface WEB [Ch. Ney]
  • Le Kanban peut-être une étape suivante pour une équipe qui maîtrise et stagne avec un fonctionnement Scrum, pour aller plus loin et gagner encore en efficacité, mais Kanban peut aussi être utilisé avec des novices en agilité [L. Morisseau]

Sessions Agile Innovation (donc pas d’orateur en particulier) :


Agile Innovation - Le cercle - Crédit photo : Arnaud Pierrel

  • Contrat agile :
    • Est un engagement de moyens, humains mais surtout autour de la méthode et des engagements réciproques autour de cette méthode : rôles, cérémonies, présences, disponibilités, informations à fournir, etc … J’ai repartagé l’idée de Jean-Pierre Gasnier pour un livre blanc, annexe au contrat
    • Des solutions peuvent être bâties par exemple autour de « tranches fermes » et de « lots de commandes », ou encore d’engagements forfaitaires sur les releases, voir les itérations, mais pour moi, toutes ces solutions sont intermédiaires, pas vraiment agiles avec des risques pervers
    • Il faut du courage pour aller au bout de la démarche, sans oublier de former/informer les acheteurs et juristes chez le client
    • Selon le contexte, il faut savoir renoncer à l’agilité (pour une autre approche), voir renoncer à un client !
  • Seul et agile ?
    • En travailleur isolé, ne pas hésiter à mettre en place des éléments de l’agilité, Scrum ou Kanban : tableau à post-its, ingénierie agile, définition du terminé, etc … Tout cela nécessite rigueur et courage, bravo à Laurent qui a su le faire dans son contexte
    • Mais ne pas oublier la partie « gestion de projet », avec notamment une bonne acquisition du besoin, si possible en contact directe avec les utilisateurs finaux
    • Et ne pas hésiter à mettre en place des échéances pour un produit partiel et opérationnel et faire des démos, voire de mettre à disposition des utilisateurs
    • Même isolé, un développeur peut être agile dans son organisation, et se doit de l’être vis-à-vis de son entourage, en douceur, avec diplomatie et informations.
    • Et par moment, il peut quitter sa casquette de développeur pour évangéliser l'agilité autour de lui !
  • Agilité et équipe distribuées :
    • Si on avait le choix, on ferait autrement …
    • Certaines situations sont moins critiques : tous les membres de l’équipe sont « isolés », ou encore l’équipe est découpée en plusieurs groupes
    • Et certaines situations sont pires : seulement quelques personnes « isolées » alors que les autres sont en groupes
    • Nécessité que les gens se rencontrent physiquement, voire travaillent ensemble sur 1 ou 2 itérations et boivent des bières ensemble
    • Attention aux différences de cultures, de langues (éviter les blagues)
    • De toute façon, prévoir des moyens pour les transports et rencontres fréquentes, mais également pour mettre en place une logistique et un outillage performant
  • Le Scrum Master peut-il / doit-il être neutre :
    • Beaucoup d’échanges intéressants sur les limites du rôle de SM, peut-il proposer, inciter, imposer, …
    • Tout le monde doit rester dans son rôle : le PO pour le fonctionnel, l’équipe pour la technique, et le Scrum Master pour la méthode
    • Quid des pratiques ? Le SM peut-il inciter voire imposer des pratiques (voire des choix) ? Oui, s’il le fait volontairement, consciemment et de façon provisoire, pour aider l’équipe
    • Les personnes présentes ont confirmé mon idée qu’un SM doit avoir comme objectif de devenir inutile, signe que l’équipe et l’entreprise sont agiles (…. Ou pas)
    • Pour le SM, j’ai bien aimé le comparatif (risqué) avec le parent qui accompagne son enfant vers l’autonomie, en lui faisant beaucoup de choses au début, puis de moins en moins, sans oublier le passage par l’adolescence où les limites seront testées pour bien les cerner et les comprendre : à méditer …

La session de Alexis Monville et Bruno Sbille


Un retour d’expérience de coachs agiles, avec les bons et les mauvais moments qu'un coach peut rencontrer au sein d'une entreprise. Les orateurs ont monté une session très vivante sur le thème de « The agilists », inspiré de « The artist » pour le diaporama et les illustrations. Sous forme de scénettes, les 2 compères sont à tour de rôle Coach, Scrum Master ou Manager pour aller chez le spy, ce qui leur permet de pointer, sous un angle différent, les réactions qu’on peut constater lors d’une migration vers l’agilité. La session est en plus très pragmatique en pointant les pièges et les bonnes pratiques, j’aime ! On repart avec des confirmations, des mises en gardes, des idées, cool !

J’ai bien aimé la réaction du manager de manager par rapport à une équipe qui expérimente Scrum et les post-its : « Ils affichent des trucs de partout, ils appellent ça du management visuel, mais le management … c’est moi ! ».

Et je trouve intéressante la comparaison du choix de l’agilité avec le choix, pour Nero, dans Matrix, entre la pilule bleue ou rouge : rester dans l’illusion ou passer dans la réalité et voir les problèmes. A méditer …

Un grand merci pour ce bon moment !!

Le diaporama : http://fr.slideshare.net/alexis/the-agilists

Ce que j’ai moins aimé ou que je regrette


  • Trop de choix (9 tracks), et avoir peut-être fait un mauvais choix pour 1 session
  • Ne pas voir de code en live, pourtant il y en avait, mais c’était ma volonté, j’essaie de me soigner …. ;-) … A quand des journées spécial « dev » ?
  • Ne pas avoir plus souvent l’occasion de rencontrer les personnes que je commence à bien connaitre et apprécier
  • Manger par terre (Agile Grenoble)

Conclusion


Deux très bonnes journées, enrichissantes et motivantes, et surtout, plein de rencontres humaines riches et dynamisantes.

C’est bateau, mais tellement important : un grand merci aux équipes d’organisation de ces 2 évènements qui nécessitent un gros investissement pour une si belle réussite : merci et à l’an prochain (ou avant) !

Les liens vers les diaporama des sessions peuvent être trouvés dans le programme : http://sessions.agile-grenoble.org/program

Ils en parlent aussi



4 commentaires:

  1. Salut Xavier,

    Merci pour ces retours. En passant la journée au même endroit, on voit des choses très différentes (surtout avec les 9 pistes...)

    Je ne comprends pas l'intérêt d'une interface web pour le gestionnaire de sources. Peux-tu en dire plus ?

    Quant à la journée spécial dev, beaucoup de monde en parle mais plus j'y pense moins je vois l'utilité de faire des rassemblements orientés vers telle ou telle catégorie de personnes quand l'essentiel est d'amener les différentes catégories à se parler et à se comprendre.

    RépondreSupprimer
    Réponses
    1. Salut Olivier,

      Merci pour ta réaction !

      Interface web pour le gestionnaire de sources :
      Selon le contexte et les types de profils qui peuvent avoir besoin d'y accéder, une interface WEB permettant de parcourir le contenu peut être un plus.

      Journée spécial dev :
      Il faut des conférences (conf, REX, jeux, ateliers), il faut des forums ouvert (comme Agile Innovation), mais j'aimerai bien tester une journée regroupant des dévs passionnés autour d'atelier pratique pour s'éclater à coder, découvrir, partager, défier, ... ;-)

      Supprimer
  2. Salut Xavier

    Et moi j'adore quand il faut faire un vrai travail d'Agiliste ... c'est à dire prioriser en fonction de la valeur apportée.

    J'adore donc que nous ayons présenté 9 tracks à AGILE GRENOBLE 2012 et une réduction du nombre de tracks n'éviterait pas forcément l'erreur de sélection :)

    Amitié
    Alex

    RépondreSupprimer
    Réponses
    1. Salut Alex,

      Bien sûr que ça fait travailler la priorisation et c'est bien. Par contre, il faut choisir sur base d'un titre et d'un court résumé, pas moyen de demander plus d'infos au "Product Owner" (i.e. orateur), le choix est donc parfois hasardeux.

      Je me suis (un peu) trompé, pas grave. J'ai croisé des personnes qui s'étaient bien trompé, dommage ...

      Mais comment faire autrement ? Je ne sais pas. Mise en ligne des diaporama avant la conf : je suis contre. What else ? ...

      Mais c'était très bien quand même hein ! ;-)

      Amitiés aussi,

      Xavier

      Supprimer