Le 20 octobre 2009 avait lieu l’étape toulousaine de l’Agile Tour, hébergé par l’IUT Blagnac. La conférence a eu lieu sur la journée. Plus de 250 inscrits, dont moi :). Je suis un peu à la bourre pour mon retour, et il n’est pas fini. En voilà la première partie…

Programme chargé pour cette journée de conférence, entre 3 et 5 tracs en parallèle. Même si quelques présentations avaient déjà été donné au cours de SigmaT, le choix ne fut pas toujours facile.

Au final, mon choix s’est porté sur :

• Les promesses de l’agilité – Jean Marie Damas
• Introduction au Core Protocols – Emmanuel Etasse
• L’agilité dans une SSII – Guillaume Saint-Etienne
• Estimations, mesure et indicateurs agiles – Claude Aubry
• Estimations scrum : boule de cristal ou bluff ?
• Retour d’expérience : forfait scrum en équipe distribuée

Les promesses de l’agilité – Jean-Marie Damas

Jean-Marie Damas revient sur les nombreuses promesses qui sont souvent associées avec l’agilité : succès des projets, satisfaction des clients, enthousiasme de l’équipe, …) et montre les différences avec les projets classiques.

L’agilité, c’est la promesse d’un nouveau modèle économique. Il promet un retour rapide sur investissement rapide et maximisé avec la possibilité d’options. La version 2009 du Chaos Report rappelle qu’une grande partie des projets explosent (en temps ou budget) et que près d’un quart s’arrêtent avant d’avoir abouti. Dans ce contexte, l’agilité, en privilégiant le développement des fonctionnalités utiles, permet de retiré de la valeur même d’un projet avorté.

L’agilité c’est la promesse de la satisfaction du client. Satisfaire le client c’est lui fournir un logiciel qui a de la valeur pour lui et qui fonctionne. Dans un projet agile, le client est au centre de décision d’évolution du produit au cours de son développement. Il a donc la possibilité, sans que ça lui coûte plus cher, d’orienter le produit vers ses besoins et attentes.

L’agilité c’est la promesse d’une meilleur opportunité de succès. Même quand un projet arrive à terme, il a de grande chance d’être inapproprié, d’arriver trop tard sur le marche, de ne générer aucune valeur. En remettant le client au centre du dév, on écarte ce genre de chose. L’agilité permet aussi d’envisager une autre définition du succès. Un succès de l’organisation, d’un point de vue technique pour l’équipe et personnel pour ses membres. L’agilité remet l’humain au centre.

L’agilité c’est la promesse de réconcilier l’approche projet/produit. Le projet, c’est la partie gestion, le produit c’est les fonctionnalités. Dans un projet agile, le projet c’est permettre à l’équipe de faire ce qu’elle sait faire à savoir son travail de développement. Le produit c’est le client/PO et leur participation active tout au long du projet. Ces deux mondes sont alors intimement lié avec un équilibre des responsabilités.

L’agilité c’est la promesse de gérer les problèmes complexes. Visibilité, inspection, adaptation sont les points fondamentaux des processus agilles¹. L’objectif c’est de pouvoir accepter le changement et d’avoir des moyens de pouvoir réagir efficacement sans tout remettre en cause lorsque survient l’imprévu².

L’agilité c’est la promesse de ramener l’enthousiasme. Aux vices des projets classiques : individualisation, trop de contrôle, impuissance des dév face à l’architecte tout puissant,… on oppose les vertus de l’agilité : la confiance à priori, l’esprit d’équipe, la communication, l’auto organisation.

La conclusion se trouve dans le manifeste agile lui-même : derrières les promesses se cachent des valeurs et une éthique profondément humaine.

Introduction aux Core Protocols – Emmanuel Etasse

Pour moi, c’est la bonne découverte de cette conf. Merci à Olivier - l’agilitateur - Azeau de m’avoir fait remarquer cette session ovni que j’avais écartée en premier lieu.

Les core protocols, c’est le résultat de bootcamp organisés à l’origine par Jim Mc Carthy alors qu’il bossait pour Microsoft. L’idée de ces camp était de sortir une équipe de devs de son environnement de travail³ et leur a donner comme mission de concevoir et implémenter ce qui leur permettrait de faire systématiquement des logiciels de qualité, qui fonctionne parfaitement en respectant le budget et les délais⁴. Tout cela fait avec un grand nombre d’équipe. De tout cela sont sortis les Core protocol.

Il s’agit d’un ensemble d’outil permettant à un groupe de personne d’améliorer et de faciliter la communication afin de leur permettre de former une vraie équipe qui fonctionne bien.

Les protocoles/outils :

• pass : on peut signifier que l’on souhaite passer son tour sur ce sujet/question/…
• check in : je suis dans l’équipe
• check out : je peux être physiquement présent, mais c’est comme si je n’étais pas là
• ask for help : on peut toujours demander/proposer de l’aide
• protocol check : lorsqu’on pense que les outils/protocols sont mal/pas utilisés
• intention check : permet de clarifier ce que fait l’un des autres membres de l’équipe (et pourquoi, avec quel objectif)
• decider : chercher le consensus de l’équipe. Si un seul membre de l’équipe est opposée à une idée/décision, ce n’est pas bon et il faut la revoir
• perfection game : méthode pour avoir du feedback
• personnel alignement : voir comment faire correspondre les objectifs perso de chaque membre de l’équipe avec ceux de l’équipe. Chacun devrait pouvoir y trouver son compte
• investigate : méthode de questionnement pour clarifier une position

Emmanuel extrait de cela de grands principes directeurs :

• le produit reflète la qualité et les défauts de l’équipe
• faire les choses bien
• simplifier les communications
• faire converger les intérêt personnels de chacun avec les intérêts du collectif
• liberté de passer/ne pas passer à l’action (droit au joker)

Ensuite, par petit groupe, nous sommes revenus sur l’outil perfection game. Son objectif est d’améliorer le feedback que l’on peut donner. Un rapide constat montre que lorsque l’on demande du feedback sur quelque chose, il en ressort essentiellement des points négatifs, sans forcement être constructif. Dans le perfection game, pour donner du feedback, on commence par donner une note de 1 à 10. Ensuite, il faut expliquer ce qu’il faudrait rajouter pour que l’idée/projet atteigne la note de 10. Cela implique, que si on ne peut pas dire comment améliorer, il faut donner la note 10, même si l’idée/projet/… ne nous plait pas.

Ma conclusion : c’est vraiment intéressant et ça vaut le coup de s’y pencher un peu plus. J’aurai bien aimé que cet atelier dure⁵ une heure de plus, pour aller un peu plus loin dans les mises en pratique.

Et hop, je rajoute Software for your head de Jim et Michelle Mc Cartthy à ma liste de lecture⁶.

L’agilité dans une SSII – Guillaume Saint-Etienne

Bon, les slides étaient sympa, l’orateur présente bien, mais voilà.. j’ai du mal à me passionner des discours commerciaux des ssii qui essaient de nous apprendre l’agilité et comment ils envisagent de nous la revendre sans mettre vraiment parler de choses concrêtes… ça reste flou tout ça…

Et faudra qu’on m’explique avec pourquoi ils pensent toujours qu’il faut conclure avec un truc sur l’aspect ‘green’… pas encore compris le rapport avec le cassoulet.

La suite dans un prochain post, dans la semaine je pense.