Agile Tour Toulouse 2012

C’est avec grand plaisir que je me retrouve pour la seconde fois présent à l’Agile Tour Toulouse, à l’espace de congrès Diagora. Pour rappel, vous pouvez retrouver mon compte rendu de la précédente édition à l’adresse suivante : Agile Tour Toulouse 2011

Je ne ferai donc pas ici de redite des notions déjà présentées dans mon précédent billet.

Cette conférence qui dure toute la journée a rassemblé cette année près de 500 personnes dont environ une moitié de nouveaux venus.

En plus des conférences et ateliers habituels, une nouveauté a fait son apparition dans cette édition : les Open Talks. Pour les déçus qui n’auraient pas été sélectionnés afin d’effectuer des présentations ainsi que pour les gens qui se posent des questions particulières ou voudraient lancer des débats, de petites conversations étaient organisées toutes les 30 minutes à la demande des personnes présentes (il suffisait d’écrire le sujet sur un bout de papier).

Mon programme, cette fois-ci axé sur les ateliers et la mise en pratique ne m’a pas laissé ne serait-ce que 5 minutes de répit afin d’aller voir de quoi il retournait exactement.

Keynote

Après une présentation succinte de chacun des sponsors (Valtech avec une vidéo “Agilité et Rugby”, ekito qui a conçu le site de l’évènement, Kagilum qui organise un jeu pour une licence d’IceScrum et Ubleam, concurrent Toulousain des QRCodes), David Brocart et Thierry Cros nous ont offert quelques scènettes théâtrales afin de mettre en avant les valeurs liées à l’Agilité. Munis de déguisements plus criants de vérité les uns que les autres (spéciale dédicace pour Thierry avec son Tshirt Metallica et sa perruque de chevelu, son accoutrement de coach des années 80 et à David qui incarnait le CEO à moumoute de manière magistrale), les deux présentateurs ont mis en avant de très nombreuses notions : les niveaux logiques de Dilts-Bateson qui nous poussent à chercher la cause des problèmes au niveau directement supérieur à celui dans lequel ils se produisent, la nécessite de limiter le stock et d’attendre le feed-back avant d’agir, la théorie X et Y de Mac Gregor ainsi qu’un grand nombre de concepts liés au code : clean code, refactoring, tdd, YAGNI (You Ain’t Gonna Need It). Je vous enjoins encore à aller jeter un oeil à mon retour sur l’édition précédente afin de trouver plus de détails autour de ces sujets. Pour tout vous dire, cette keynote présageait sans que je le sache à cet instant précis de ce qu’allait être le programme de ma journée : particulièrement chargée.

Innovation Games (par Eric Rubinat)

Je me suis donc prestement dirigé vers le premier des 4 ateliers qui m’intéressaient particulièrement en ce jour : à savoir une mise en pratique des Innovations Games. Ce sujet me tient particulièrement à coeur, étant un grand amateur de jeux de société depuis mon plus jeune âge et étant déjà sensibilisé à leur apport en terme d’apprentissage. A mon grand regret, étant donné le nombre trop élevé de participants, le présentateur nous a annoncé la couleur d’entrée de jeu : pas de démonstration en live malheureusement. La séance s’en est donc tenue à une présentation des jeux “Innovation Games” (attention, le nom et les 13 jeux correspondants sont déposés depuis 2003 par Lukue Homan, leur créateur).

Les jeux quels qu’ils soient commencent à perdre la mauvaise image qui les accompagnait depuis bien longtemps (associabilité, déni des réalités…) et les gens commencent désormais à comprendre leur intérêt (développement de l’esprit de combativité, de la créativité, mise en place d’un lien de communication important).

On peut découper les jeux liés à notre domaine en trois ou quatre grandes catégories :

• les meeting games (comme ROTI par example : Return Of Time Invest)
• les serious games utilisés depuis bien longtemps dans des domaines tels que l’armée, la médecine etc afin de pouvoir s’entraîner et pratiquer sur des reproductions de situations réelles.
• les jeux agiles qu’on utilise le plus souvent pour enseigner des concepts utilisés dans les différentes approches agiles.

Les serious games sont utilisés le plus souvent comme leviers du ROI Agile (Return Over Investment cela va sans dire). On s’en sert pour trouver la liste des features, les prioriser…

Il ne faut pas prendre cela à la légère en tant qu’animateur : il est nécessaire de passer beaucoup de temps à préparer de tels ateliers afin que les choses se passent au mieux.

Il faut tout d’abord définir l’objectif principal, poser la BONNE question.

Il est ensuite nécessaire de planifier : prévoir les personnes, déterminer quel jeu conviendrait.

On prépare ensuite le jeu, puis on y joue.

On agrège enfin les données, sans sous-estimer le temps nécessaire. En effet, il est nécessaire de passer beaucoup de temps sur cette partie afin de tirer le meilleur parti des jeux effectués.

Enfin, on définit et on communique le plan d’action à adopter pour la suite.

Durant la session, on peut noter plusieurs rôles :

• l’organisateur
• un maître de cérémonie (peut être la même personne mais pas forcément)
• un photographe si on peut, c’est toujours plus sympa et peut permettre de voir des choses qu’on n’aurait pas vues sinon (qui a parlé d’artefacts bizarres sur les photos?).
• un observateur, qui garde un oeil extérieur et prend des notes sur des choses qui n’auraient pas été notées sinon.

Les jeux Innovation games présentés :

• le Speed Boat : une île représente l’objectif majeur, on identifie les aides, freins et esquifs qui peuvent surgir pour l’atteindre. Ce jeu peut être utilisé pour remotiver les rétrospectives ou pour les kick-off meetings.
• la Product Box : on donne du matériel de papeterie aux différents participants (ciseaux, carton, papier, colle, feutres…) et on leur donne pour objectif de définir le packaging de leur produit. Cela permet de découvrir de nouvelles features pour le produit et de les prioriser fonction de leur emplacement sur la boîte. Il est plus que fortement conseillé d’avoir un observateur pour ce jeu.
• Prune the Tree : les branches représentent des features existantes, on donne aux participants les restantes à placer sur l’arbre (sans leur permettre d’en rajouter) en considérant que plus une feature est proche de la racine plus elle est importante.

• Buy a Feature : des billets permettent d’acheter des features et sont donnés en nombre limité. D’après l’intervenant (mais pas d’après Lukue Homan…) il ne faudrait pas donner un coût par feature. Je suis en désaccord avec cette notion. Pour moi, ce jeu sert surtout en cas d’indécision du client pour le contenu des itérations et les coûts par feature doivent représenter son coût réel en temps de développement. L’intervenant a ensuite présenté brièvement une liste de jeux Agile, qui servent pour la formation et n’apportent pas de valeur produit, ils permettent simplement de faire passer un message :

• Bottle-Neck Game (60 à 90 min)
• the Real Options Space Game (90 à 120 min) : notion de décision au dernier moment
• The Toyota Way (45 à 90 min)
• Marble Run (20 à 30 min) : planification agile
• Origami (10 à 20 min) : importance de la communication -> OFFSHORE
• Swiss Army Knife (10 à 15 min)
• Start Your Day
• Remember the feature (dans 2j ? 2 ans ? 10 ans ?)

Les maîtres mots :

• Préparer
• Garder du temps pour les retours
• En lieu et place d’une réunion

Kanban par la pratique (par Laurent Morisseau)

Ne connaissant pas du tout la méthode Kanban, je me suis ensuite rendu dans cet atelier pour en savoir plus. Le jeu (un serious game disponible sur getKanban.com) était un jeu de plateau avec 7 dés à 6 faces de 3 couleurs différentes (2 rouges pour le design, 3 bleus pour le développement et 2 oranges pour les tests). Des cartes avec des points à compléter dans chaque catégorie sont disposées dans des colonnes avec un nombre d’éléments limités. Le but est d’arriver à remplir les cartes avec les dés et à les faire avancer dans les différentes colonnes sans créer de blocages. Les dés lancés comptent double si on les affecte à la catégorie pour laquelle ils sont prévus, simple sinon.

Des impondérables viennent rythmer la partie pour corser un peu et rendre le jeu plus intéressant.

Il permet de se rendre compte de l’importance de la fluidité de la chaîne de bout en bout et de l’importance de limiter le nombre de tâches simultanées dans chacune des catégories. Le temps moyen de réalisation par tâche s’en retrouve lissé et plus prévisible.

Cependant, on constate rapidement que cette méthode de gestion permet d’accomplir certaines actions prioritaires à une cadence énormément plus élevée qu’à la normale, et semble donc potentiellement plus souple.

Pour en avoir discuté par la suite avec la personne qui nous faisait cette présentation, cette méthode est particulièrement adaptée dans les cas où l’agilité serait mal perçue, et permettrait d’effectuer une transition en douceur.

Piqué au vif, je tâcherais donc d’en savoir plus prochainement à ce sujet.

Et un carpaccio ! Un ! (par Géry Derbier)

Rencontrant parfois des problèmes de découpage de tâches avec certains clients, j’ai voulu essayer de voir si cet interlocuteur n’avait pas par hasard la solution miracle. Eh bien non !

La séance consistait à découper une problème très simple : le calcul du prix total en appliquant une ristourne fonction du montant total de la commande et en appliquant des taxes fonction de la région géographique.

La séance était constituée de 5 itérations de 8 minutes. A la fin de chaque itération, il fallait montrer une nouvelle fonctionnalité développée.

Autant dire que le timing était serré, d’autant plus que j’ai voulu, comme à mon habitude dans ce genre de cas partir sur une approche en TDD. Ceci dit notre groupe s’en est aussi bien sorti que les autres au final : les tests en plus !

Projet dont vous êtes le héros (par Antoine Vernois et Pablo Pernot)

Autant le dire tout de suite, c’était là mon gros coup de cœur de la journée. Je me suis régalé.

3 ballons étaient disposés dans la salle et notre groupe devait répondre à des questions liées à l’agilité en se rapprochant de l’un des 3 fonction des questions posées.

Les questions étaient assez ambiguës pour que des doutes se posent et que chaque réponse puisse sembler valable à certains.

Une petite discussion s’installait du coup sur les résultats. Si la majorité des personnes s’était trompée, on procédait à une épreuve subsidiaire (des petits jeux agiles).

Nous évoluions ensuite sur une carte en choisissant notre prochaine destination.

Le contexte était sympa, les questions pas mal tournées et souvent drôles, les discussions intéressantes et les jeux instructifs, un vrai régal !

Je ne saurais que vous conseiller d’aller jeter un coup d’œil sur le site du jeu

Cependant, si vous comptez assister à cet atelier lors d’un prochain atelier, évitez.

Agile Unlimited (par Alexandre Boutin)

J’avais adoré les présentations d’Alexandre Boutin l’an dernier et attendais donc avec impatience sa note de clôture. Ses slides tournaient cette fois-ci autour de l’univers de Star Trek et traitaient de l’application possible des méthodes Agiles à d’autres domaines que l’informatique. Effectivement, on peut reprendre les concepts suivants assez facilement :

• le Management Visuel à grands coups de Post-It
• le stand up d’équipe
• la rétrospective
• la Vision Partagée
• l’Ordonnancement
• les Boîtes de Temps (le fait de borner le temps alloué aux réunions et de filtrer les participants utiles)

Cependant, de nombreux freins se lèvent au sujet de cette adoption :

• les REX personnels
• la tolérance à l’erreur dans certains domaines
• le Command & Execute
• les problèmes de Communication
• la Visibilité (certaines personnes n’ont pas forcément envie que ce qu’ils font comme travail soit plus transparent)
• l’Autonomie (certains préfèrent travailler seuls)
• le Travail Répétitif

Le point principal abordé par Alexandre et sur lequel il a le plus insisté est qu’on ne peut pas faire d’agilité si la culture de l’entreprise ne s’y prête pas. L’agilité est une histoire de culture et nécessite bien souvent un changement de culture, qui est un processus particulièrement difficile.

Ainsi s’achève mon deuxième Agile Tour Toulouse. N’hésitez surtout pas à me demander des précisions !