Homo Agilis

La liste du Père Noël de mes enfants

2011-11-26T11:55:00.000-08:00

Aujourd'hui notre PO (Product Owner) à la maison, nous fixe l'objectif de définir et de commander les cadeaux de Noël des garçons... Après avoir posé la question "Bon les enfants, que voulez-vous cette année?", il a été difficile de couper les réponses des garçons et de les obliger à faire un choix... le budget de la famille n'étant pas extensible. Il faut préciser que mes 2 grands (5 et 8 ans) partagent beaucoup leurs jouets et ils ont essayé de négocier entre eux des cadeaux à acheter en commun. C'est une situation finalement typique où des "clients" doit faire des choix en fonction des moyens dont ils disposent.

Là, je me dis que c'est l'occasion rêvée d'essayer d'appliquer à la maison ce que j'utilise au travail !!!

Le temps d'aller chercher quelques post-its, un feutre et des pions, nous avions animé un petit atelier "buy a feature" avec Samuel et Robin, les garçons. Au bout d'une minute, nous avions 5 post-its correspondant aux jouets d'une marque connue dont le thème tourne autour d'un garçon - sorcier de métier - ayant une cicatrice sur le front. Dans un second temps, nous avions valorisé chaque jouet avec un nombre d'étoiles proportionnel à son prix (voir la seconde photo). L'échelle allait d'une à 3 étoiles.

Nous avions ensuite donné à chacun des deux garçons un nombre de pions en fonction d'un budget fixé par nos soins. 2 minutes plus tard, tous les pions avait été posés sur les post-its, les enfants avait parfaitement compris le principe et avaient fait toutes sorte de négociations, de compromis en passant même par du chantage et des menaces.

Bref, au bout du compte, nous étions satisfaits du résultat obtenu et nous nous sommes dit que c'était la meilleure liste du Père Noël que les garçons pouvait nous faire, en 5 minutes...

Remarque : j'ai pu voir que le fait que les pions soient tous de la même couleur, ça n'aide pas... en effet, assez souvent, en cas de conflit, il fallait se souvenir de qui avait posé quoi sur quel jouet, afin de défaire un "accord" devenu caduque : jouer avec des pions de couleur pourrait être un plus.

Et vous ? Si vous essayez de votre coté, je serais curieux de savoir comment ça c'est passé.

Agile Grenoble 2011 - Les coulisses

2011-09-26T07:39:00.000-07:00

Les gentils organisateurs (Manuel, Laurence, Anne-Laure, Jean-François, Sébastien, Alex, Cyril et votre dévoué) travaillent dur en ce moment pour vous préparer une édition 2011, meilleure que l'année dernière. L'équipe déplore cependant la perte de Silvan et d'Aline, mais on espère les revoir le jour J. Johan, quand à lui, a rejoint l'équipe! Nous voilà 9 dans la dernière ligne droite...

Voici nos prochaines actions :

choisir le traiteur : cette année, dégustation de plusieurs lunch bags et plateaux repas ! (ça se passera le mardi 27 chez /ut7)
définir le programme parmi 50 sujets proposé ! J'espère un premier programme disponible début octobre,
choisir les goodies et le sac pour les participants,
faire le design de l'affiche de l'évènement : euh... si quelqu'un a des idées ou de l'énergie, pourrait-il m'aider ?

Pour les plus curieux (voire très indiscrets) sachez que l'organisation de cette conférence est réalisée en toute transparence à travers le wiki de l'association.

Vous souhaitez nous aider le jour J ? (jeudi 24 novembre) Nous avons toujours besoin de mains durant la journée! Préparation des sacs, accueil des participants, gardiens du temps, prise de photos... ce n'est pas les tâches qui manquent... alors même pour une heure ou deux, si vous voulez contribuez à votre façon, dites nous !

Pour finir voici quelques liens utiles sur AG2011:

le site de la conférence : http://agile-grenoble.org/
vous inscrire (obligatoire, 30€) : http://agile-grenoble.org/2011/inscription

Sachez qu'il existe un second évènement inédit le lendemain d'AG2011 (vendredi 25 novembre) : Agile Innovation pour les passionnés et les praticiens dont toute l'information est disponible ici.

Recherche des développeurs JAVA sur Chambéry

2011-09-02T08:13:00.001-07:00

Je relaye cette annonce car elle pourrait bien faire un ou plusieurs heureux ! La société FDI Logbox recherche activement un ou plusieurs ingénieurs JAVA. Le cadre de développement en place est Scrum (eh ben oui). Voici l'offre d'emploi :

Nous recherchons de jeunes ingénieurs motivés et talentueux pour un projet ambitieux :

(Plusieurs postes à pourvoir)

Société en développement dans le secteur du « business process outsourcing », secteur en croissance de 15% par an, FDI Logbox,, Groupe international présents dans 9 pays depuis 1984, est le leader du « financial relationship management »,

Dans le cadre de la mise en place de la refonte complète de notre plateforme applicative utilisée par l’ensemble de nos collaborateurs, la Direction informatique complète son équipe de développeurs de haut niveau capable de prendre en charge le développement en faisant appel aux dernières technologies

Sous la conduite du responsable du pôle développement, vous participez à l’élaboration et aux développements de cette plateforme. Votre dynamisme, votre sens de l’initiative et votre force de proposition sont des atouts pour la conception et la mise en œuvre technique de ce projet.

Votre participation à des projets pérennes sur notre plateforme technique orienté services vous permettront de développer et diversifier vos compétences.

Formation

Ecole d’ingénieur informatique avec ou sans expérience
Les technologies JAVA , Flex 4, spring, hibernate ,V4, SOA,
Expérience JAVA exigée
La conception orientée objet.

Les clés de votre réussite sur ce poste

Capacité d’analyse et d’écoute,
Créativité et professionnalisme
Esprit d’équipe
La faculté d’adaptation à un environnement innovant et en constante évolution.

Salaire : Attractif en fonction de l’expérience et du profil

Poste en CDI basé à Chambéry (73)

la procédure : Envoyer Lettre de motivation et CV par mail : recrutement _at_ fdi-logbox _point_ com

J-1 : Mix-IT à Lyon le 5 avril

2011-04-04T02:26:00.000-07:00

Demain c'est la première MIX-IT à Lyon : il s'agit de la première conférence d'ampleur organisée par le JUG (Java User Group) Lyon et le CARA (Club Agile Rhône Alpes) ! Une journée exceptionnelle autour de l'agilité, des technologies Java/JEE et des tendances novatrices. Le Touilleur Express (aka Nicolas Martignole) sera le "keynote speaker" de la conférence, et vous y rencontrerez toute la communauté agile venu des 4 coins de la France... Toutes les places ont été vendues et il n'est pas pas possible de s'y rendre au dernier moment, dommage ...

Anne-Laure et moi sommes heureux de faire partie des sponsors de cette conférence et d'y présenter un atelier jeu : Buy a Feature ! Ce jeu fait partie des "innovation games" de Luke Hohmann. L'objectif du jeu est de prioriser une liste de fonctionnalités pour un produit donné : c'est souvent un exercice difficile qui incombe au "Responsable Produit" et cet atelier propose une alternative ludique et efficace pour faire émerger les décisions des utilisateurs eux-mêmes.

Notre atelier se passe à 16h40 dans le "track" Gamy. Ne tardez pas, le nombre de places est limité à 30 personnes ;-)

Présentation de Scrum au chapitre PMI France Sud à Lyon le 24 mars 2011

2011-03-15T08:14:00.000-07:00

Le 24 mars prochain, j'ai l'honneur d'animer une présentation en compagnie de Jean-François Jagodzinski devant tout plein de monde, venu d'horizon très varié, majoritairement intéressé par la gestion de projet, mais pas forcément dans le domaine logiciel.

Cette conférence proposée par le PMI France Sud (branche Rhône Alpes) est organisée en partenariat avec le Club Agile Rhône Alpes ainsi que l'INSA Lyon.

Ouvrir des portes entre des mondes aussi "différents" que PMI et Agile, c'est quelque chose que j'ai à cœur même si l'exercice peut être parfois risqué. L'objectif de cette conférence est de sensibiliser l'auditoire à l'existence d'approches nouvelles, vraiment différentes, donnant à la fois plus de sens et plus de pragmatisme au sein des projets, pour faire gagner avant tout les personnes.

JF et moi avons tout fait pour que la conférence soit la plus attractive, accessible et interactive possible. Venez nous rejoindre ;-)

Le programme ainsi que les infos pratiques sont disponibles ici.

Attention : inscription en ligne obligatoire.

A très bientôt j'espère ;-)

Formation aux techniques de Virginia Satir du 27 au 31 mai 2011

2011-03-11T07:30:00.000-08:00

Je suis particulièrement heureux de relayer cette information : Emmanuel Gaillot et Raphaël Pierquin organisent une formation / introduction aux techniques de Virginia Satir. Cette formation sera animée par Maria Gomori, une des principales élèves et collaboratrices de Virginia Satir.

Pour mémoire, Virginia Satir est l'un des psychothérapeutes fondateurs de l'École de Palo Alto, qui développera la discipline de thérapie familiale systémique. Virginia est la récipiendaire de titres honorifiques prestigieux et a influencé quantité de gens de par le monde. Parmi eux, Gerald Weinberg, dont les écrits séminaux sur la programmation logicielle sont l'une des sources de l'eXtreme Programming.

La formation aura lieu à l'Hôtel Arnold à Itterswiller en Alsace (France), du vendredi 27 mai 2011 à 19h30 au mardi 31 mai 2011 à midi. Le nombre de places est limité à 22 participants.

Je crois que cette formation vous intéressera, et je serai ravi si vous pouvez vous joindre à nous. Si vous pensez que d'autres personnes pourraient être intéressées par cette formation, n'hésitez pas à leur transmettre cette invitation. N'hésitez pas non plus à contacter Emmanuel (egaillot chez ut7.fr) ou Raphaël (rpierquin chez ut7.fr) si vous avez des questions.

Agile Grenoble 2010 : J - 5 !!!

2010-11-17T05:25:00.000-08:00

Agile Grenoble édition 2010 c'est la semaine prochaine et la ruche des organisateurs s'active!

Hier c'était la préparation des 450 sacs des participants... tenue de sport oblige ;-)

Le 23 j'aurai l'honneur de présenter deux sessions :

- Atelier Story Map : là où tout commence... en co-animation avec Olivier Pizzato

- Behaviour Driven Metrics : même les métriques peuvent être agiles! en co-animation avec Alexandre Boutin

Venez rencontrer la "team" ut7 (Anne-Laure, Eloïse, Olivier, Manu, Eric) et même notre président Martin au stand ut7 ! Et participez à un tirage au sort pour gagner un iPad !

Enfin, consultez le programme pendant la conférence sur votre smartphone tactile en ouvrant votre navigateur à l'adresse http://agile-grenoble.org/mobile/(application faite par nos soins ;-)

Albums Photo Agile Tour

2009-10-27T16:37:00.000-07:00

Ouf, jeudi dernier le A319 touche la piste de Saint Exupéry et ma tourné des Agile Tour s'achève après avoir participé à 4 villes (Genève, Paris, Grenoble et Toulouse) et 6 sessions.

Voici quelques photos prise durant mon passage dans ces villes : Genève Grenoble Toulouse

Agile Tour Grenoble 2009, c fini

2009-10-27T16:19:00.000-07:00

Agile Tour Grenoble 2009 est fini… après des mois de préparations, je suis très ému par les retours que j’ai pu obtenir. 300 personnes étaient présentes durant cette journée. Les agilamis du CARA étaient partout : à l’accueil, à la gestion du temps, dans les sessions. Un cadre de prestige avec un amphithéâtre plutôt confortable. Des horaires respectés à la minute près. Un grand merci aux 20 orateurs pour le niveau de leur intervention, certains d’entre eux sont venus de très loin ;-) De Stockholm pour Henrik Kniberg et d’outre-Atlantique pour Elisabeth Hendrickson !

Merci aussi aux sponsors de l'étape grenobloise : leur donation est précieuse pour un évènement de cet ampleur!

Je tiens à remercier du fond du cœur mes co-équipiers de l’organisation de cet évènement : Georges Allemand, Emmanuel Huguonnet, Anne-laure Dalban, Alexandre Boutin, Yves Crespin, Cédric Bourgeois, Arnaud Pierrel, Laurent Laslaz, Laurence Hanot, Pierre Maciejewski, Jérôme Barrand, Arnaud Pierrel, Jean-François Jagodinski... Tout le monde a donné de son temps, de son énergie et je crois qu’on peut être fier du résultat !

Le dépouillage des 220 feedbacks recueillis à la fin de la journée nous attend et un rapport de synthèse sera très bientôt disponible en ligne. De même que les présentations seront très bientôt en ligne ;-) Enfin, on se donne rendez-vous très prochainement pour faire la rétrospective grenobloise. Au fait, si un volontaire (extérieur aux organisateurs) est partant pour animer cette rétrospective, qu’il nous contacte !

Pour les plus curieux, voici mon album photo Agile Tour Grenoble 2009.

Premier BarCamp à Grenoble

2009-09-15T12:54:00.000-07:00

Pour redémarrer l'année des réunions mensuelles du CARA, Rémy Sanlaville et Emmanuel Hugonnet vous proposent de vivre l'expérience du premier AgileCamp à Grenoble, qui sera animé par Luc Bizeul.

Qu'est-ce qu'un BarCamp ? Quand cela se passera-t-il ? Comment s'inscrire ?...
Toutes les réponses à vos questions sur la page web dédiée : http://barcamp.org/AgileCampGrenoble1

Agile Tour Grenoble 2009, c parti!

2009-09-08T14:28:00.001-07:00

Après le succès de l'édition 2008, Le Club Agile Rhône Alpes, association pour la promotion des méthodes agiles, organise pour la seconde année consécutive l'étape Grenobloise de l'Agile Tour.

Les méthodes agiles visent à améliorer l'efficacité des entreprises et la satisfaction du client final. Ces méthodes proposent de nouvelles approches en termes de pratiques de développement logiciel, de gestion de projet (MOA/MOE), mais aussi sur les aspects organisationnel et de management dans l'entreprise. Sur un plan financier, les méthodes agiles permettent de réduire significativement le coût du changement et assurent au maître d'ouvrage de disposer d'un produit fonctionnel fiable, testé et utilisable en production tout en respectant le budget fixé initialement.

L'Agile Tour est un évènement à but non lucratif organisé dans 18 villes à travers le monde, il vise un public de décideurs, d'acheteurs, de managers et d'informaticiens qui souhaitent découvrir ou approfondir les méthodes agiles. Durant la journée vous seront proposées des sessions variées en simultané dans plusieurs espaces (retours d'expériences, exposés techniques, ateliers pratiques …) animées par des orateurs internationaux et locaux de renom:

Henrik Kniberg, l’auteur du fameux “Scrum and XP from the trenches”;
Marie-Pia Ignace, l’une des créatrices de l’Institut Lean France;
Elisabeth Hendrickson, experte reconnue dans le domaine du test et de la qualité logicielle en mode Agile;
Jérôme Barrand, professeur à Grenoble École de Management, fondateur de l'Institut d'Agilité des Organisations et auteur du livre "Le Manager agile" ...

Le programme, en cours de finalisation, compte plus d'une vingtaine de contenus réparti sur 6 tracks durant toute une journée.

Un évènement à ne pas manquer !

Bénéficiez d’un tarif spécial en vous inscrivant dès maintenant pour l’évènement de Grenoble. S'inscrire !

XP-Days Paris 2009

2009-08-14T08:04:00.000-07:00

Après 3 semaines de vacances bien méritées, je reprends la plume électronique pour consigner mes impressions sur les XP-Days 2009. Oui je sais, j'ai un peu de retard à blogguer sur cet évènement qui s'est passé en mai dernier... Je sais que bien d'autres ont déjà couché leur impressions sur leur blog alors j'essaierai de ne pas répéter leur propos, en donnant une version très personnelle de ces deux jours.

Ce fut la seconde fois que j'assistais à l'évènement et cette fois en tant qu'orateur. J'étais assez fier d'arborer mon teeshirt rouge pompier Pyxis, qui d'après certains témoins, pouvait se voir à des kilomètres à la ronde. Bon, depuis Anne-Laure m'a ramené une taille S de son voyage au Québec et j'espère que l'effet sera un peu plus atténué. J'ai principalement animé l'atelier XtremMiles ou autrement dit "séance de codage XP autour du fameux jeu des mille bornes"! J'avoue avoir été déçu par la faible participation du public à cet atelier : je mets ça sur le compte peut-être d'un manque de communication de notre part sur le déroulement de l'atelier, mais aussi par l'envie du public d'aller vers des sujets moins techniques? Eh... n'oublions pas que coder c'est l'activité la plus importante dans nos métiers : sans code, pas de produit, pas de service ;-) Précisons aussi que cette année, nous avions décidé de démarrer l'atelier avec la base de code générée l'année dernière... oups... on peut alors comprendre que c'est dur de reprendre le code déjà écrit par un tiers... mais n'est-ce pas là notre lot quotidien de développeur? J'aime beaucoup la formule qui définit la qualité de code de cette façon : "un code de qualité c'est un code qui peut évoluer facilement dans les mains d'une autre personne"... eh oui, nous sommes nous-même toujours enclin à trouver que notre code est beau, mais ce n'est pas le plus important : est-il "vraiment beau" pour un autre? J'ai pris pas mal de plaisir en codant avec Arnaud Bailly, Vincent Tencé, Yves Crespin et d'autres dont je ne connaissait pas le nom.

Ma seconde intervention fut une courte démonstration de GreenPepper, un produit Pyxis qui gagne a être connu en vertu de ses fonctionnalités avant-guardistes et de sa capacité à s'adapter à des tonnes d'outils du monde JAVA, .NET et très bientôt Ruby. C'est surtout Vincent qui a mené la danse, le test agile c'est vraiment son dada, il assure! Les outils pour faire des spécifications exécutables, du BDD ou du TDR murissent petit à petit. Je suis intimement convaincu que nous n'en sommes qu'au début et que demain, la validation manuelle des spécifications fonctionnelles ne sera qu'un lointain souvenir ;-)

J'ai eu le plaisir d'assister à la session de Géry Derbier sur "Les 90 minutes d'une équipe remarquable". J'ai adoré sa prestation, son humilité et ses propos qui touchent juste : on ne mettra jamais assez l'accent sur la communication! Sans que Gery n'ait prononcé le mot de "Core Protocols", j'ai bien reconnu ces outils mise en œuvre durant la session. Cette session m'a donné envie d'animer une session de ce genre à Grenoble (ce que j'ai fait depuis). L'objet de cette session était de donner des outils pour briser la glace et ouvrir les canaux de communication au sein d'une équipe en pleine formation.

J'ai assisté à la session "Scrum est-il dangereux?" présentée par Eric Lefevre-Ardant et Guillaume Tardif. J'avais l'impression d'assister à un jeu de rôle où deux camps s'affrontaient à coup de phrase chocs : il y avaient les "pros" et les "contres" de Scrum : une palme d'or tout de même de la meilleure interprétation à certains "contres" qui se forçaient outrageusement à dire du mal de Scrum ;-) J'ai pu voir alors certains de mes collègues (formateurs Scrum) devenir vraiment rouges, souffler ou bien répondre à devant tant de mauvaise foi. Certains témoignages marquants sur de douloureuses implémentations de Scrum m'ont toutefois ému. L'intervention dont je me souviens le mieux c'est celle d'Emmanuel Gaillot en réponse à :
"On ne peut pas dire qu'un outil soit dangereux, cela dépend de son utilisation! Cela dépend de la main qui le tient..."
Emmanuel répond alors "Et quand il s'agit d'un revolver, tu dirais la même chose?" ;-)
J'ai donc passé un bon moment, et au final, je reste bien persuadé que Scrum est un superbe outil pour notre profession, une réelle opportunité de rendre meilleures nos organisations, en particulier sur le plan humain et social.

En dehors des sessions, j'ai manqué de temps pour « rézoter »mais j'ai tout de même discuté un moment avec Jacques Couvreur et François Bachmann, qui m'ont complètement impressionné avec leur entreprise personnelle du jeu Alchimiste Agile, jeu qu'ils veulent commercialiser, c ENORME.

A l'année prochaine, sans faute pour un Agile France 2010 encore plus fun!!!

Leçon apprise n°3 - Les intéractions et les individus

2009-07-01T01:57:00.000-07:00

Ce que j'ai pu voir durant ces années de pratique agile à Grenoble, c'est la facilité avec laquelle Scrum ou eXtreme Programming peuvent être vus simplement comme de nouveaux "processus". Il en résulte que certains peuvent appréhender ces concepts pour les accommoder à leur vision du travail et finalement les détourner de leurs objectifs premiers. Mais au fait, quels sont ces objectifs? Revenons à la première valeur du Manifeste Agile est

"Les interactions et les personnes"
ont plus de valeur que
"les processus et les outils"

Cela signifie qu'il est plus important d'expliquer, de communiquer les valeurs, les principes, les comportements attendus, de favoriser la communication d'adulte à adulte, bref de gérer les humains que de veiller à la mise au point des processus et de la mise en œuvre des outils. Il s'agit là d'une petite révolution culturelle car bien souvent dans nos organisations, on s'attache à ce qu'il doit être fait, plutôt qu'a la façon dont les choses sont faites.

Les approches agiles sont des moteurs à apprendre non seulement quoi faire, mais aussi mieux faire la prochaine fois. Les comportements associés sont à la fois des aptitudes à communiquer, inventer et décider en équipe mais aussi la faculté individuel de se remettre en cause pour faire mieux, pour d'améliorer en continue. Faire mieux ne veut pas dire aller plus vite : c'est de la qualité des interactions de l'équipe dont nous parlons. Une mesure de cette qualité réside avant tout dans une écoute active des individus de cette équipe : accorde-t-on cette oreille attentive? Cette activité pourrait faire partie des attributions d'un Coach Agile, mais n'est pas aussi le rôle des managers de l'organisation de communiquer les valeurs et les comportements attendus des uns avec les autres?

Lecon apprise n°2 - Adapter la structure

2009-06-17T01:12:00.000-07:00

Deuxième billet sur mes leçons apprises lors d'une expérience de 4 ans d'application de Scrum/XP chez un éditeur de logiciel à Grenoble. Avant, je veux clarifier le terme "structure". Ce que je veux dire par "structure" c'est la cartographie de l'organisation en terme d'organigramme : la pyramide hiérarchique ou chaîne de commandement... on oppose souvent l'approche projet à cette structure pyramidale. En approche projet, on va travailler en mode transverse à de nombreux départements ou services.

Constat

En agile, les choses deviennent pire : on veut créer des équipes dédiées pluri-disciplinaires. De nouveaux rôles transverses apparaissent et on a du mal à les placer sur l'organigramme de l'organisation. A l'inverse des rôles existants se voient "dépouiller" de leurs activités du fait du changement de méthode. Dans notre cas, à l'époque, les chef de projets, responsables d'équipe et leaders techniques (architectes) ont eu beaucoup de difficultés à faire "leur trou" dans cette nouvelle façon de travailler. Le fait d'avoir conserver un grand moment une structure de l'entreprise inadaptée, cela a nuit au bon déroulement de la transition. Je n'ai jamais compris pourquoi cela semblait si compliqué de modifier la structure en place.

Pistes d'amélioration

Ne pas attendre pour introduire (valoriser) les nouveaux rôles dans la structure de l'organisation
Adapter ou supprimer la définition des rôles existants si ils sont obsolètes
S'appuyer sur une description processus/responsabilité plutôt que structure/autorité
Dans une approche processus, le rôle de ScrumMaster prend tout son sens : c'est le gardien ou le pilote du processus, à l'échelle d'un projet, d'une équipe
Maintenir un backlog de transition agile pour y consigner justement les adaptations de structure à conduire
Impliquer la RH le plus tôt possible dans la transition car le système de mesure de la performance individuel doit être adapté à cette nouvelle façon de travailler

Leçon apprise n°1 - Transition en douceur

2009-06-11T00:28:00.000-07:00

Un mois déjà depuis mon dernier billet : je me ressaisis en entamant une série de 5 ou 6 billets sur les leçons que j'ai apprises durant ces dernières années d'accompagnement agile à Grenoble.

Leçon apprise n°1 - Transition en douceur

La transition vers l'agilité à laquelle j'avais assisté et dont j'étais aussi acteur, fut menée en mode "big-bang" : du jour au lendemain, tous les projets de l'entreprise furent gérés en Scrum. Le travail de préparation avait essentiellement porté sur des études de livres et la recherche de prestataires en formation et conseil agile. Nous avions organisé une grande réunion (ou plutôt une grande messe) pour expliquer les changements imminents et les raisons de ce changement. Je ne remets pas en cause ce que nous avions fait, mais je pense que nous manquions de maturité sur la gestion du changement à l'échelle de l'entreprise, et surtout sur les individus. Nous n'aimons pas changer quand quelqu'un décide à notre place, mais nous aimons changer si cette décision vient de nous... à méditer ;-)

J'aime l'image du lièvre et de la tortue : ne pas confondre vitesse et précipitation. Vouloir tout changer c'est bien mais savoir aider les autres à changer c'est mieux. La majorité des personnes veulent mieux faire, veulent s'améliorer et si elles vous paraissent hermétiques au changement, c'est que le problème ne vient pas forcément d'elles mais peut-être de de votre façon de leur parler et de les écouter.

Les bonnes pratique que je vois pour une transition en douceur sont les suivantes:

Impliquer un maximum de personne dans la décision de changer (et pas seulement le management et la direction)
Présenter ce changement "possible" à tout le monde (formation, ateliers...) avant de démarrer
Commencer avec UN projet pilote avec LES personnes qui souhaitent changer
Etre attentif aux arguments des personnes qui ne veulent pas changer et les entendre
Gérér formellement un "backlog" de transition en toute transparence en y agrégeant les idées de tous
Identifier une équipe en charge de ce "backlog"

Au final, on constate que pour démarrer, on a pas besoin d'avoir tout le monde d'accord : c'est une bonne nouvelle : une équipe motivée et un projet, ça suffit ;-)

Le lycée collaboratif existe, depuis 1982

2009-05-11T06:22:00.000-07:00

Aujourd'hui, un reportage surprenant sur le Lycée expérimental de Saint-Nazaire diffusé sur France 2. Ce lycée expérimental créé en 1982 est un établissement scolaire public cogéré par les professeurs et les élèves : élèves et professeurs partagent droits et devoirs. Des équipes d'élèves se relaient tous les 15 jours et assurent ainsi tout le fonctionnement de l'établissement. Hum... des équipes (de jeunes de 20 à 25 ans environ) sont changées et la gestion fonctionne en continu... on sait faire ça dans nos métiers?

Des élèves en difficulté scolaire peuvent y trouver leur compte et réussir ici (obtenir leur diplôme BAC) ce qu'ils échouent dans une structure traditionnelle. Des élèves témoignent qu'ils sont confrontés à des expériences inédites : travail en équipe, collaboration avec des adultes, tout cela leur donnent une grande confiance en eux. Ici, ils ont le droit de l'ouvrir, s'exprimer... ailleurs on leur disait seulement d'écouter et de travailler. Dans cet établissement, la sanction n'a plus lieu et l'autorité a été remplacé par la responsabilisation. Son taux d'obtention au BAC est le plus bas de France (50%) et s'explique par le fait qu'il y a dans cet établissement une plus grande proportion de jeunes en situation de difficultés scolaire.

Éducation, éducation... quelle sont tes critères de succès?

Une question de confiance

2009-04-17T10:47:00.000-07:00

La confiance, mais c'est quoi au juste dans une équipe de développement logiciel? Ben, c'est pas très différent de celle d'une équipe de sportifs... Pour information, ce sujet a déjà été abordé dans les mêlées et à travers le livre de Patrick Lencioni "The Five Dysfunctions of a Team". Notre culture favorise-t-elle le développement de la confiance dans notre travail? J'ai envie de vous signaler ce podcast de Eric Mignot et Raphaël Pierquin sur Visual Talk Show. Le but de l'emission n'est pas de dévoiler le contenu du livre, loin de là, mais plutôt de vous donner envie de le lire! J'ai pris pas mal de plaisir à l'écouter pendant mon vol d'aujourd'hui Bordeaux-Toulouse. Ca m'a aussi donné envie de faire un BBQ ;-) Bravo les gars et merci pour votre témoignage!

Vers une Administration Agile?

2009-03-19T11:12:00.000-07:00

Hier matin, j'ai entendu le médiateur de la république française qui parlait de son rapport publié aujourd'hui, dans une émission de radio nationale sur le service public.

Voici un commentaire de ce rapport sur les Echos:
Déficits d'information, réponses aléatoires, sentiment d'arbitraire : dans son dernier rapport publié hier, le médiateur de la République, Jean-Paul Delevoye, ne ménage pas ses critiques vis-à-vis de l'administration. A l'heure de la RGPP (révision générale des politiques publiques) et de la modernisation des services publics, il semble que les effets positifs pour les usagers tardent à se concrétiser. Jean-Paul Delevoye a notamment insisté, hier, sur le manque d'attention porté aux réclamations des usagers : « Ce n'est pas une question de moyens, mais plutôt de culture. La gestion des réclamations est cruciale pour améliorer la qualité de service. Ce qu'ont très bien compris les entreprises privées, mais pas encore l'administration. »

D'après les propos que j'ai entendu, le médiateur de la république a reçu cette année 65 000 courriers des citoyens français. 65% concernent des demandes d'information, des réponses erronées ou contradictoires données par les administrations. Il s'interroge "Pourquoi de nos jours, à l'ère de l'information, c'est si difficile pour le citoyen de connaître ses droits?". D'après lui, plus que jamais, les citoyens ont besoin de réponses, ont droit à l'information!

La journaliste de l'émission lui demande

"Et les fonctionnaires? Peuvent-ils être plus performants?"

Sa réponse est à peu près la suivante:

"Les employés de l'état sont les autres victimes du système en place; les lois sont trop compliquées, il n'y a pas assez de délégation, de droit à l'erreur; on ne fait pas appel à l'intelligence et au bon sens des agents, mais plutôt à leur capacité à suivre des procédures trop lourdes; il y règne la culture de la faute, et non pas celle de l'erreur; le législateur doit simplifier les textes. Ce qui compte c'est la qualité du service, la satisfaction des utilisateurs, et cela passe par changer la culture en place."

Hum... voudrait-il faire du refactoring des lois existantes? Voudrait-il rendre le système moins hiérarchique? Laisser plus d'autonomie aux employés? Voudrait-il rendre "lean" notre administration? Houla... J'avoue que ce genre de discours, ça me fait du bien, même si ce n'est pas pour demain ;-)

Esprit Agile à Marseille

2009-03-18T01:05:00.000-07:00

Hier, mardi 17 mars, je me suis rendu à la soirée de lancement de la communauté agile sud-est à Marseille « Esprit Agile ». En tout 80 personnes étaient présentes dans l'amphi de l'Ecole Centrale Marseille : réunir tout ce monde sur le sujet, en soirée, c'est déjà un beau succès! Le programme s'est déroulé à bâton rompu et avec passion : introduction à l'agilité, description de Scrum, description de eXtreme Programming puis retour d'expérience ViaXoft, le tout ponctué d'applaudissements et de questions.

Environ 25% du public avait déjà « pratiqué » de l'agilité. La présentation d'eXtreme Programming m'a fait me rappeler que XP n'est pas « juste » un ensemble de pratiques d'ingénierie, comme on le présente généralement, mais bien une méthodologie à part entière, avec de fortes similitudes - il est vrai - avec Srum. Thierry a bien insisté sur les aspects humanistes de l'Agile, ça m'a plu! Le terme « Développement responsable », ça m'a bien plu aussi. Le retour d'expérience, quand à lui, m'a un peu frustré, time boxing oblige, j'aurai voulu en savoir plus: Eric Barthelemy de la société ViaXoft nous a présenté très humblement les choses qui ont bien marché, mais surtout les «difficultés» rencontrées et les « adaptations » effectuées durant leur mise en place agile pour le développement de leur produit interne.

Parmi les questions posées dans l'auditoire, on a senti une certaine tension lorsque la question des « aspects financiers » fut lancée : c'est un peu déconcertant de devoir justifier des bienfaits financiers d'une démarche, lorsqu'on a passé près d'une heure à expliquer que la principale motivation de cette démarche était justement d'augmenter la valeur ajoutée du produit réalisé... mais cette défiance est légitime tant on est formatés à suivre une méthode sans trop s'interroger sur son efficacité.

J'ai retrouvé Jean-Marie Daumas avec plaisir, on a bien échangé.. Ce fut super de rencontrer enfin Claude et Thierry, en chair et en os, autrement que par blogs interposés! Je fis aussi la connaissance de Karine Mazet, correspondante du French Scrum User Group dans la région PACA et ScrumMaster chez ViaXoft. Surprise pour moi, il y avait des agilistes praticiens venus de Montpellier pour cette soirée! Comme quoi, beaucoup de régions étaient présentes ce soir-là!

Pour conclure, souhaitons que l'Esprit Agile se diffuse le plus possible. Pour cela, on a besoin de bras, beaucoup de bras, pour faire du vent, pour agiter les consciences ;-)

Approches Agiles dans les grandes entreprises

2009-03-10T07:12:00.000-07:00

Quels sont les enjeux rencontrés par les grandes organisations lors d'une transition vers les approches agiles? Comment convaincre les organisations? La transition est-elle toujours possible?

Voici le témoignage de François Beauregard sur Visual Studio Talk Show, président de Pyxis Technologies qui nous livre sa vision actuelle des choses après plusieurs années de pratiques.

Le podcast est ici. Bonne écoute!

Esprit Agile

2009-02-18T15:51:00.000-08:00

Un nouveau feu s'allume près du Vieux Port, on le distingue à peine du haut de la Canebière, il annonce la naissance d'une nouvelle tribu. Bienvenue à "Esprit Agile"! Que votre esprit soit aussi pur et aussi puissant que le Mistral ;-) Une nouvelle communauté agile démarre à Marseille. Invitations lancées pour le 17 mars prochain. J'espère vous y rencontrer bientôt...

Amélioration continue : trouver l'erreur...

2009-02-08T23:50:00.000-08:00

C'est quoi l'amélioration continue? C'est un terme qui revient souvent ici et là...

l'amélioration continue est l'un des quatre domaines des exigences de la norme ISO 9001 (v2000), par là, elle entend des mesures et des enregistrements de la performance à tous les niveaux ainsi que l'engagements d'actions de progrès efficaces.
le mot Kaizen en japonais désigne une philosophie de travail, qui signifie un changement constant, une amélioration continue à petits pas qui n'a pas de fin. Cette méthode est utilisée dans diverses méthodologies comme le Lean, le Kanban, le PDCA, etc..
dans Scrum, le temps de la rétrospective est mis à profit pour améliorer les pratiques de l'équipe.

Même si tout le monde semble d'accord sur l'importance de l'amélioration continue, est-ce que chacun est prêt à jouer le jeu? Tout le monde est-il d'accord pour s'améliorer en tant que personne? J'ai parfois le sentiment qu'on oublie un peu souvent que l'amélioration de nos façons de faire passe avant tout par le travail que nous devons faire sur nous-même. Qu'avons-nous appris durant les X dernières itérations? Nous somme-nous remis en cause face à un dysfonctionnement? Avons-nous progresser grâce à nos erreurs? Car c'est bien en se trompant, en commettant des erreurs que nous pouvons progresser. Encore faut-il que notre environnement de travail nous le permette...

Notre environnement tolère-t-il les erreurs? Où bien vise-t-il à sanctionner les personnes, et à identifier les fautes? La culture de la "faute" est propice à un climat où chacun fuit ses responsabilités, chacun vise à assoir sa propre position en cachant le plus possible les éventuels dysfonctionnements. Fuyons ses environnements de travail pour des environnements où l'amélioration est récompensée! Alors, regardez autour de vous et... trouvez l'erreur...

Le CARA à la soirée Agile Alliance

2009-02-02T02:05:00.001-08:00

Le 15 janvier dernier, s'est tenue une soirée organisée par l'Agile Alliance à Vincennes. Le but de cette rencontre était de faire connaissance avec les différents groupes et associations qui soutiennent localement l'agilité. Il était donc important que le CARA y soit représenté! Nous partîmes en grand renfort (à cinq) depuis Grenoble vers la capitale...

Les membre du board de l'Agile Alliance étaient présents et disponibles. Les discussions (in english, sir) fuseaient dans toute la salle, tandis que des petits canapés et le champagne étaient servis. En parallèle aux discussions informelles, il nous a était demandé de travailler, de remplir de grandes feuilles blanche pour expliquer comment nous voulions que les organisations soient connectées les unes aux autres. Dans un second temps, sur la base des dessins faits aux murs, nous échangions tour à tour sur les façons d'aider chaque organisation locale dans sa mission. En plus d'un soutien financier, l'Agile Alliance pourra contribuer à nos évènements, notamment en y envoyant des orateurs clefs.

Au final, je dirais mission réussie et j'en veux pour preuve ce cliché rapporté par Eric Lefèvre sur son blog. Le CARA y est bien représenté! Notez aussi une mention spéciale pour nos Coding Dojos!

Le mythe de l'auto-organisation?

2009-01-21T02:38:00.001-08:00

Les approches agiles (y compris le Lean) renforcent le degré de responsabilisation des équipes dans leur travail quotidien. Le but est donc de laisser les équipes décider. On peut en retirer les avantages suivants:

c'est la personnes qui effectue une tâche, qui sera la plus à même d'estimer correctement le temps nécessaire à sa réalisation, d'anticiper les problèmes à venir ou de proposer des pistes d'amélioration.
l'efficacité d'une personne se voit améliorer si elle fait preuvre de plus d'autonomie : il est plus motivant d'être l'acteur de ses propres décisions, plutôt que de "subir" la décision d'une tierce personne.

En combinant ses avantages à l'échelle d'une équipe, si chaque membre se sent réellement impliqué et mobilisé autour de l'objectif commun, la performance de l'équipe sera grandement améliorée!

Mais bien souvent, on associe auto-organisation avec chaos; le sens commun nous incite à croire que si il y a pas de chef il n'y aura pas de décision. On nous dit que le consensus est une utopie (merci Thomas ;-) pour son billet). Heureusement, nous ne sommes pas obligés d'adhérer à ces croyances.

Sur un terrain de sport, les membres de l'équipe savent ce qu'ils doivent faire, ils ont été entrainés par un coach... l'intelligence de leur jeu est plus élevée que la simple somme des intelligences de chacun. Pouvons-nous en dire autant dans nos projets?

Mais quelles sont les conditions nécessaires à cette auto-organisation? 3 axes pour tenter de répondre à cette questions :

L'équipe est-elle réellement identifiée?
Les membres peuvent-ils compter les uns sur les autres à tout moment? Les membres de l'équipe sont-ils des ressources partagées ou des membres investis et impliqués? Scrum insite sur ce point grâce à la fameuse blague des cochons et des poulets. Clairement, une bonne pratique consiste à se focaliser sur le moins de choses possibles à faire à la fois. J'aime la remarque d'un collègue qui me disait un jour "A la maison, le matin, est-ce qu'on est efficace si on se brosse les dents en habillant le petit dernier, tout en préparant son biberon, alors que le téléphone sonne..."

Les membres d'une équipe partagent-ils un objectif commun?
C'est souvent le cas mais on constate trop souvent qu'il existe des enjeux personnels, des incompréhensions, bref, toutes sortes de freins à la cohésion de l'équipe sur l'objectif, la façon de l'atteindre ou simplement une décision le concernant. Il n'y a pas de solution miracle pour adresser ce point. Travailler la communication et le développement interpersonnel des acteurs du projet sont des pistes à considérer. Suivre des formations en communication c'est excellent, personnellement ça m'a ouvert les yeux sur pas mal de choses. Mais n'oublions pas le rôle du coach d'une équipe... j'ai bien dit coach, pas chef ;-) Son but est bien de faire grandir l'équipe, d'aider cette dernière à gagner en auto-organisation. Mais au delà de l'objectif commun de l'équipe, il y a les valeurs, les croyances et les motivations de chaquun des membre : sont-elles alors compatibles avec celles des autres membres? Sont-elle alignées?

L'équipe peut-elle décider?
Quel est la zone de contrôle de l'équipe? Quel est son pouvoir de décision? Quels sont les moyens mis à disposition de l'équipe? Dans Scrum ce n'est pas l'équipe qui décide du "quoi faire?", c'est plutôt le Product Owner. Néanmoins, c'est l'équipe qui est responsable du "comment faire?". Or, toute décision engage des moyens (réallocation de ressource, changement de méthode, etc...). Si une équipe n'a pas de tels moyens, peut-elle réellement décider?

Si l'une de ces conditions n'est pas remplie, peut-on encore espérer l'auto-organisation? J'avoue que ma vision du travail d'équipe est largement inspiré des Core Protocols. C'est que j'y trouve des principes simples, claires, pragmatiques et universels (enfin à quelques cultures près). Ca me parle le simple et le pragmatique! De votre coté, de décidez-vous pour laisser plus d'autonomie à vos équipes? Si vous êtes dans une équipe, êtes-vous aligné avec les objectifs de votre équipe?

Première formation CSM à Grenoble!

2009-01-18T05:26:00.000-08:00

J'ai le plaisir de vous annoncer que François Beauregard viendra du Québec pour animer une formation Certifiante ScrumMaster dans notre belle région à Grenoble les 12 et 13 février prochains. Il s'agit de la première formation de ce type ouverte au public dans notre région. Les informations et l'inscription sont disponibles en ligne. La formation est co-organisée par la société Pyxis et l'association Club Agile Rhône-Alpes (CARA).

Groupe des Utilisateurs Français de Scrum

2009-01-11T14:47:00.000-08:00

Je souhaite la bienvenue à cette toute nouvelle formation : le SUG-France (Scrum User Group en anglais dans le texte) dont la première rencontre se tiendra à Paris le 19 mars prochain en présence de Jeff Sutherland (l'un des pères fondateurs de Scrum). Le groupe herbergé sur meetup compte déjà plus d'une centaine d'inscrits! Les fondateurs du groupe envisagent de créer une association à but non lucratif, sorte de relais local en France de l'association internationale ScrumAlliance. Pour info, il existe de très nombreuses "antennes" de la ScrumAlliance à travers le monde.

"Etre Agile" ou "Faire de l'Agile" ?

2008-12-21T12:30:00.000-08:00

Cette question revient souvent sur le tapis. Elle peut paraître dénuée d'intérêt de prime abord, mais je trouve qu'elle résume à merveille le bouleversement silencieux que peut représenter l'Agilité. Pour illustrer mes propos, j'en veux pour preuve les fondements du manifeste Agile; vous n'y trouverez aucune solution toute faite, pas de processus, pas d'outils non plus... vous y trouverez tout simplement des VALEURS.

Il est vrai toutefois que ces valeurs peuvent se décliner dans les différentes activités de l'entreprise qui développe du soft: pratiques d'ingénierie, gestion des tests, gestion de projets, analyse du besoin, etc.. il en résulte bien évidemment des outils, des méthodes (comme Scrum), des pratiques (comme celles d'eXtreme Programming) et bien d'autres choses, mais n'attendez pas de pouvoir simplement réutiliser clef en main ce qui marche ici pour l'implémenter là-bas. L'histoire des constructeurs automobiles américains copiant en vain les procédés de Toyota (approche Lean) montre que les richesses d'une entreprise sont parfois invisibles, trop subtiles pour être photographiées. Une culture, un état d'esprit, ça prend un certain temps pour se construire. Aussi, n'attendez pas des résultats immédiats, mais préparez vous à investir aujourd'hui pour demain.

L'Agilité est donc à mon sens plus un savoir-être qu'un savoir-faire. Ce savoir-être peut nécessiter une révolution des mœurs dans l'entreprise! Il faut s'attendre à pas mal de résistance dans les situations suivantes:

les chefs de projets n'affectent plus les tâches quotidiennes des équipes
les décisions d'architecture sont prises par les équipes
les managers communiquent sur les comportements attendus et les valeurs au lieu du règlement et des procédures
les équipes décident par elles-mêmes si une personne devrait être "sortie" du projet
les évaluations individuelles s'appuient sur une évaluation par ses propres collaborateurs
l'entreprise développe les motivations et les talents des collaborateurs
les relations d'autorité sont remplacées par de la collaboration gagnant/gagnant
toute l'information disponible de l'entreprise est accessible par tous

Cela vous parait-il ubuesque, démagogique, inapplicable? Ben, j'aime les débats qui pourraient survenir! Attention, je ne cherche pas à dire que l'Agilité est la panacée à tous les maux; je ne dis pas non plus que l'Agilité est meilleure qu'une autre démarche. Je veux juste mettre en garde sur ses conséquences sur l'entreprise, en terme de management, c'est à dire au niveau de la gestion des hommes. Ce management conscient des valeurs (qu'elles soient ou non celles de l'agile) offre - quand il existe l'avantage de pouvoir aligner les forces de l'entreprise dans un même effort.

Beaucoup de courants de pensée (en dehors du développement logiciel) alliant performance, humanisme et écologie m'incite à croire que la complexité grandissante de notre monde nous condamne à nous remettre en question un peu plus chaque jour ;-)

Agilité chez Orange

2008-12-18T13:38:00.000-08:00

Hier, j'ai été invité à intervenir à un Webinaire interne à Orange Labs (ex France Telecom). L'objet du séminaire était d'introduire et d'expliquer l'agilité avec retours d'expérience à la clef. Il y avait 17 présents dans la salle et 60 en conférence web.

Je remercie Hervé Lourdin de m'avoir proposé d'animer avec lui sa présentation "Agile Démystifiée". Le principe de cette présentation est de faire participer le public en leur demandant de prioriser les questions qu'ils veulent poser, sachant que les animateurs auront une période de temps fixe pour y répondre. Le public devient ainsi le "product owner" (ou directeur de produit dans Scrum) et doit faire des choix pour rentabiliser au mieux le temps d'animation qu'il a à sa disposition. Marrant le vote à main levée dans la salle, complété par les votes par "chat" pour ceux qui étaient sur le net. Nous avions abordé les sujets suivants

L'intégration continue
Contrat au forfait ou en régie?
Les outils pour faire de l'agile
Spécification agile

Ensuite Thomas DONY a présenté son retour d'expérience sur un projet d'Orange Labs géré en Scrum depuis 1 an. Le bilan du projet est positif et il est question d'étendre l'expérience. Enfin, j'ai présenté mon retour d'expérience chez Varian après 3 ans de Scrum/XP, discours relativement proche de celui tenu par mon collègue Bruno Orsier à l'Agile Tour 2008 à Grenoble.

Le timing global de l'après-midi était assez serré, ne laissant pas beaucoup de place aux questions/réponses. Parmi les questions soulevées durant les retours d'expériences, j'ai pu relever :

Comment puis-je faire de l'agilité sachant que j'ai des points de recontres très précis (contenu et date) avec mes fournisseurs?
Puis-je introduire de l'agilité sur la partie "amont" seule (travail sur le backlog, avec des échelles de temps de l'ordre d'une release) ?
Comment être agile dans un environnement où le top-management est plus "directif" que "participatif"?

Dommage que nous n'ayons pas pu faire un ROTI (return on time investment) afin de mesurer le degré de satisfaction du public, bien que j'ai su par la suite directement et indirectement que l'après-midi fut très appréciée!

Merci à Rémy et Pierre qui m'ont invité, ce fut un plaisir de contribuer à leur démarche pour faire connaître l'agilité au sein de leur grande société.

XP et Scrum depuis les Tranchées

2008-11-28T02:39:00.000-08:00

Ce matin, j'ai deux raisons d'être content! La première c'est qu'il y a 10 cm de neige dehors (oui, je suis un grand enfant et j'aime la neige! même si j'ai mis 2 heure pour atteindre le bureau ce matin).

La seconde raison c'est le mail d'infoQ qui m'informe que le livre que nous avons traduit est disponible en ligne! Guillaume, Bruno, Christophe et moi-même avons travaillé dur durant les 6 derniers mois sur notre temps libre pour traduire le livre d'Henrik Kniberg intitulé "Scrum et XP depuis les tranchées". Depuis ce matin, il est à vous, gratuitement sur le site d'infoQ:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Il s'agit d'un ouvrage qui fait référence dans le domaine, une vrai mine d'or pour la mise en place pratique de l'agilité dans une entreprise!

Je remercie encore mes coéquipiers Bruno, Guillaume et Christophe pour leur disponibilité, leurs efforts, sachant que nous avons complètement opéré à distance sans jamais nous rencontrer. Techniquement, nous avons mis en place les outils suivants

* un backlog partagé sous forme de feuille de calcul (liste des tâches de traduction, relecture, vérifications, etc... qui? quand?)
* un dictionnaire partagé pour assurer une homogénéité de traduction des termes récurrents (comme Product Owner qui est devenu Directeur de produit)
* un wiki collaboratif pour s'échanger les morceaux du livre

Ce fut une expérience très enrichissante (maintenant je comprends mieux la gestion des sections et des entêtes dans MS Word ;-)

PNL (Partie 1) - Niveaux logiques

2008-11-27T03:57:00.000-08:00

C'est en lisant le livre Les 3 types de coaching d'Alain Thiry que j'ai fait une première excursion dans la PNL (programmation neuro-linguistique). Il s'agit d'un petit (par la taille) livre qui explique certaines techniques de coaching en se basant sur des cas concrêts.

Quel rapport entre PNL et Agilité? Ben... pour moi, les méthodes agiles reposent sur des valeurs comme l'esprit d'équipe, une communication sincère, l'engagement... La PNL donnent des outils de communication qui peuvent aider les équipes, les coachs, les managers, les chefs d'entreprises à obtenir le meilleur d'eux-même. Alors pourquoi s'en priver?

Parmi les différents outils présentés dans ce livre, les niveaux logiques de Robert Dilts sont très utiles. Les niveaux logiques sont :

Système : ce niveau correspond à notre système (le corps humain, notre "hardware").
Identité : c'est le "software" qui nous définis comme une personne unique, un "software" qu'on ne pourra jamais modifier donc.
Convictions : c'est l'ensemble ne nos croyances, nos valeurs... il est possible que nos convictions changent avec le temps ou selon les événements.
Compétences : c'est notre "savoir faire", issu de nos apprentissages
Comportement : c'est notre "savoir être", la façon dont on se comporte dans notre environment, dont on communique aussi.
Environnement : c'est le milieu externe avec lequel on intéragit

Cette approche permet par exemple d'expliquer les 3 différents types de coaching :

le coaching de compétence où l'objet est de travailler sur les niveaux compétences, comportement et environnement : par exemple, une personne peut apprendre une nouvelle façon de s'organiser, ou alors apprendre à utiliser un nouvel outil.
le coaching de performance où la personne travaille sur l'alignement de ses convictions avec son identité (un principe primordial est que l'identité ne se modifie pas!). Grâce à ses alignement interne, la personne pourra s'épanouir, et donc "performer".
le coaching stratégique (ou d'entreprise) s'opère à tous les niveaux : à la fois en travaillant sur la stratégie de l'organisation, sa structure, les rôles, les convictions des individus, etc... Le but est de réussir à aligner un maximum toutes ces entités afin d'optimiser la performance globale de l'organisation.

Une seconde utilisation de ces niveaux logiques permet d'analyser un problème... La plupart du temps, un problème est difficile à formuler... les différentes parties prenantes ne partagent pas la même vision du problème. Une première étape à sa résolution devrait être un débat (voire un consensus) sur la nature du problème : quel est son niveau logique? S'agit-il d'un problème d'environnement? De comportement? De compétence? Là encore, ne pas oublier que l'identité ne doit jamais être un problème (on doit accepter l'identité d'une personne ;-). Cette façon d'analyser un problème permet de dédramatiser, ou au moins, permet d'aborder les différents point de vue des parties prenantes.

Auto-organisation transverse

2008-11-11T16:13:00.000-08:00

La semaine dernière, j'ai été invité à une session de sensibilisation aux erreurs d'ergonomie des IHMs. Cette session m'a particulièrement ému : j'y ai ressenti de la satisfaction et de la fierté pour l'équipe des animateurs. Le but de la session était d'expliquer à plusieurs équipes Scrum du même projet comment conduire des revues informelles visant à détecter des problèmes d'ergonomie. La session, rondement menée tour à tour par les différents animateurs, était découpée en 3 parties : expliquer l'objectif de ces revues, l'utilisation pratique du support de revue, et enfin un exercice collectif. Le tout en 60 minutes chrono!

La beauté de la chose pour moi, c'est que les animateurs sont des membres de ces mêmes équipes Scrum, organisés dans un groupe de travail transverse aux équipes. Ce sont à la fois des développeurs et des experts du domaine qui ont travaillé depuis plus d'un an sur l'amélioration de la qualité des IHMs dans leurs équipes Scrum.

Durant cette période, ils se sont complètement appropriés le superbe document de 100 pages que j'avais écrit il y a des années (et que presque personne ne lisait ;-). Ils ont fait preuve de pragmatisme et de courage en se heurtant parfois à la direction sur la mise en place des solutions qu'ils voulaient mettre en œuvre. Ils ont fait preuve de courage aussi pour prendre le temps nécessaire pour ce réunir, pour préparer les sessions, alors que le contexte du projet focalise plutôt les équipes à faire des points.

Aujourd'hui ils ont su créer une dynamique qui semble efficace et qui est soutenue par le Product Owner du projet A mes yeux c'est un superbe exemple d'auto-organisation qui a su dépasser le cadre d'une seule équipe pour s'attaquer à une vraie problématique projet. Je rêve qu'une telle dynamique puisse voir le jour pour d'autres aspects comme l'architecture, la qualité de code, etc... Il serait très utile de discuter avec ce groupe de travail pour tenter d'analyser les raisons de leur succès.

En ce qui concerne ce concept de "revue informelle", je précise qu'il s'agit de revues faites le plus tôt possible durant l'implémentation d'une fonctionnalité, et ce, par une personne si possible extérieure à l'équipe. Les résultats de la revue n'engagent que l'équipe en charge de la fonctionnalité, il n'y a pas obligation de correction des défauts soulevés. En fait, cette revue informelle est surtout un moyen de partager les compétences entre les équipes et le groupe de travail espère que le nombre de défaut diminuera avec le temps, preuve que la solution choisie aura été efficace ;-)

Bienvenue à Bruno

2008-10-30T16:52:00.000-07:00

Je souhaite la bienvenue à Bruno Orsier, collègue, ami et inspirateur dans la nébuleuse blogosphère ;-) Ses premiers billets sont pour les conférences AgileTour de Grenoble et Valence. Notez aussi ses nombreuses contributions sur developpez.com sur les bonnes pratiques de tests et de POO.

Le But

2008-10-30T16:31:00.000-07:00

Coup de cœur pour le livre Le But écrit par Eliyahu Goldratt (père de la théorie de contraintes). Ce livre est un vrai roman qui vise à nous faire comprendre des concepts assez indigestes de prime abord. Concepts qui ont tout à fait leur place dans la boîte à outils de l'Homo Agilis ;-)

L'histoire raconte la périlleuse quête d'un directeur d'usine qui a 6 mois pour sauver son entreprise. En effet, ce directeur d'usine apprend du jour au lendemain que son usine n'est pas rentable alors que tous les indicateurs de processus sont bons, que les rendements de ces machines sont les meilleurs du secteur. Abasourdi, ce dernier mettra un certain temps pour savoir par où commencer... heureusement, il croisera une vieille connaissance à lui, un expert de l'optimisation des processus, gourou mathématicien aussi, qui lui donnera de sérieux tuyaux... à déguster.

AgileTour Valence

2008-10-24T04:33:00.000-07:00

AgileTour 2008 s’est terminé hier à Valence… Vive AgileTour 2009 !

J’ai beaucoup apprécié cet après-midi passé à Valence. Je m’y suis rendu avec mon collègue et ami Bruno. Le niveau des sessions, la qualité des échanges ainsi que le buffet ont été au rendez-vous. Le tout a été orchestré d'une main de maître par les organisateurs! Chapeau bas!

L’atelier « Artistes et Specifieurs » animé Gery Derbier m’a énormément plu. On y découvre de façon ludique les écueils possibles dans la communication entre client et développeurs, et surtout les moyens pour arranger les choses. Je ne regrette pas d’y être allé !

Le retour d’expérience d’Alexandre Boutin sur l’implémentation de Scrum chez Yahoo ! en Europe, Asie et Canada m’a beaucoup plu ! Il y était question du choc des cultures. On relève au passage qu’Alexandre avait initialement tenté d’implémenter du cycle en V, mais a du retourné sa veste (du bon coté) en choisissant une démarche Agile. Je retiens aussi que la démarche initiale était un processus imposé visant à contrôler, alors que la forme Agile est un framework optionnel facilitant l’adoption de Scrum mais sans le rendre obligatoire : « On peut forcer quelqu’un à suivre un processus, on ne peut le forcer à être Agile... ». Enfin, une raison obligatoire au succès de la démarche est l'engagement du management.

J’ai ensuite assisté à une petite partie du forum ouvert animé par Alexandre, où il était question du rôle des spécialistes dans une approche agile et du sujet brûlant de la contractualisation au forfait.

Enfin, Gery Derbier a présenté la méthode Crystal de Alistair Cockburn décrite dans les livres Agile Software Developpement et Crystal Clear. J’y ai retenu que cette méthode pouvait s’apparenter à un framework où les pratiques concrètes doivent s’adapter en fonction du contexte et de la vie du projet. Ce framework s’appuie sur des points théoriques :

Le développement logiciel est un jeu coopératif d’invention et de communication avec deux objectifs antagonistes : livrer un produit et se préparer pour la partie suivante.
Le produit délivré par une équipe est à l’image de celle-ci

Crystal s’appuie 3 propriétés principales : livraison fréquente (au moins tous les 6 mois), communication de proximité entre tous les développeurs (moins de 30 sec pour obtenir une info), réflexion tactique pour s’améliorer (une fois minimum tous les 2 mois). Crystal me fait penser à une méta-méthode, relativement "universelle" en fait.

Dans les couloirs, j’ai beaucoup apprécié mes échanges avec Laurent Bossavit, Géry Derbier, Emmanuel Chenu, Emmanuel Hervé, ainsi que bien d’autres que j’oublie… ca fait sacrément plaisir d’échanger, d’apprendre, on se sent moins seul dans le désert ;-)

La Troisième Question

2008-10-21T08:16:00.000-07:00

Dans Scrum, la troisième question de la mêlée quotidienne (daily scrum) consiste à savoir si l'équipe rencontre des obstacles. En général si on vous pose la question de bon matin « Ca va ? », vous répondez naturellement « Oui » même si vous avez un gros souci dans la tête. Si j'étais consultant, je dirais qu'il s'agit d'un « meta programme » bien connu en PNL ;-)

(euh, je n'ai rien contre les consultants et la PNL)

Dans Scrum, c'est souvent pareil; à la question « Vous avez des problèmes ? » , les équipes répondent « Non, tout va bien » .

Les expériences passées m’ont conduit à penser que la première chose à faire pour un Scrum Master c’est de reformuler la question de façon ouverte afin d’obtenir un maximum d’information. La seconde chose est de s’assurer que l’équipe comprend que cette question ne concerne pas seulement les obstacles destinés au Scrum Master, mais surtout les obstacles internes à l’équipe elle-même ! L’objectif est ici d’éviter le réapprentissage (éviter que des membres tombent dans un piège déjà connu par les autres). Il y a d'autres objectifs derrière cette question, mais ce sera pour une autre fois.

C’est en animant une équipe expérimentée en tant que Scrum Master durant cet été que j’ai eu une sorte d’illumination sur cette fameuse 3^ème question. En cogitant les notions Lean de temps de cycle, de gestion de priorité, et je dois dire aussi sous influence de l’excellent livre de E. Goldratt « Le But », que j’ai eu envie de reformuler cette question sous cette forme :

« Quels sont les obstacles que nous rencontrons et qui nous empêchent de finir cette user story que nous avons commencé en premier ? »

(à noter le « nous » dans la question qui permet de dire clairement que le Scrum Master est avec l’équipe ;-)

En effet, si le but est de réduire le temps de cycle (ou de réalisation par l’équipe), la théorie nous dit que l’on travaille plus efficacement si on se concentre sur une seule tâche à la fois. Dans un monde idéal toute l’équipe devrait travailler sur la même User Story. Or, ce n’est pas tout le temps possible dans la vraie vie, mais il n’empêche que la tâche la plus vieille devrait être la plus prioritaire devant les autres. Une sorte de « Hot User Story » marquée en rouge pour que l’équipe puisse se focaliser sur celle-ci en priorité, les tâches relatives à celle-ci devenant automatiquement prioritaires devant toutes les autres.

Dans la pratique, même si cette reformulation parait séduisante, il s’avère qu’elle est insuffisante. Il ne suffit pas à un Scrum Master d’être persuadé d’avoir vu la lumière pour convaincre ses collaborateurs. L’intérêt de la question posée ne vaut que si l’équipe est prête à l’entendre. Or, il arrive parfois qu’une équipe à l’esprit bien trop occupé pour réfléchir à des aspect jugés trop théorique, ou tout simplement en dehors des préoccupations de l'équipe… mais ceci est un autre problème ;-)

Prioriser des demandes d’amélioration d’intégration continue

2008-10-21T04:32:00.000-07:00

Je voudrais partager cette pratique que je me suis imposé récemment. Le problème à résoudre était le suivant :

"Comment prioriser les demandes d’amélioration de notre plateforme d’intégration continue ?"

En effet, les équipes y détectent souvent des pistes d’améliorations. Ces améliorations ont pour but de leur permettre de travailler plus efficacement. Comme nos ressources pour modifier nos outils d’intégration continue sont assez limitées, il faut faire des choix, prioriser les demandes et délivrer en fonction des priorités. Un tel backlog existe depuis très longtemps mais il n’y a jamais eu de notion de priorité à l’intérieur. Les demandes étaient traitées selon la règle de « celui qui parle en dernier » ou la règle de « celui qui parle le plus fort ».

A un moment, pour résoudre le problème, je fut tenté de faire voter les équipes pour qu’elles définissent elle-même la valeur des demandes d’amélioration. Un peu comme un planning poker. Ce processus avait pas mal d’inconvénient :

disponibilité des équipes pour voter
la décision de faire telle ou telle chose repose sur un vote «au feeling» et non sur du «factuel»
il se peut que de grosses différences de perception surviennent pendant les votes (des discussions certes intéressantes peuvent se tenir, mais au final le processus peut prendre beaucoup de temps)

Nous n’avons jamais tenté cette méthode.

M’inspirant de l’approche Lean, j’ai essayé de poser chaque demande d’amélioration du point de vue « Muda » (=gaspillage). Par intégration continue, on entend en fait une « ligne de production logicielle » dont le but est de convertir une ou plusieurs modifications de code en un produit terminé. Chaque attente sur cette « chaîne de montage » introduit un délai supplémentaire dans le temps de réalisation. Les demandes d’amélioration peuvent être vues comme des moyens de supprimer ces attentes. Le résultat d’une amélioration est donc un gain de temps de disponibilité de la plateforme afin de traiter de nouvelles modifications de code.

Partant de cela, avec l’aide de membres des équipes, nous avons estimé le gain de temps (=réduction de « Muda ») engendré par chaque demande. En adoptant le point de vue d’une User Story, on exprime la valeur de la demande dans l’unité « Heure.UserStory/Jour ». Par exemple une valeur de 2 signifie un gain de disponibilité de la plateforme de 2 heures par jour pour une User Story en cours de développement. Introduire la notion de « Heures.UserStory » permet de tenir compte du fait que l’amélioration aura un impact sur plusieurs User Stories en parallèle.

Je ne suis pas un expert du product backlog produit mais j'imagine que la même démarche pourrait être utilisée pour quantifier précisemment la valeur d'une fonctionnalité utilisateur : comment cette fonctionnalité pourra faire gagner du temps à l'utilisateur? Comment cette fonctionnalité lui apporte une réelle valeur, chiffrée?

Reste ensuite à estimer la taille de développement de chaque demande. En calculant ensuite le rapport Taille/Valeur on peut alors s’attaquer aux demandes qui auront le meilleur retour sur investissement.

Paysages virtuels

2008-10-20T11:53:00.001-07:00

Récréation. Terragen est un petit bijoux de logiciel que je connais depuis des années. Il permet de créer des "paysages virtuels" comme ce superbe coucher de soleil. Il intègre un modeleur de terrain, des textures de surface (neige), un moteur de ray-tracing tenant compte de centaines paramètres (atmosphère), un rendu pour des nuages 3D, un gestionnaire pour les étendues liquides comme les lacs (ou la mer), etc... très facile à prendre en main... essayez pour voir ;-)

Les trois registres

2008-10-20T04:29:00.001-07:00

Aujourd’hui, un petit peu de communication… il parait que c’est la raison #1 de presque tous nos échecs, que ce soit dans le travail ou à la maison ;-)

J’ai suivi une formation sur la communication en début d’année. Je dois avouer qu’elle m’a beaucoup apporté. Je suis très loin de maîtriser les outils que la formatrice nous a enseignés, mais il n’en reste pas moins que certains principes appris ne me quittent plus.

Voyons l’un de ces outils : quand on s’exprime, nous le faisons selon 3 registres différents :

le registre factuel : on exprime les faits tel qu’ils se sont produits, sans interprétation ni arrière-pensée, le plus objectivement possible
le registre des émotions : on exprime ses propres émotions (joie, tristesse, peur, colère etc..) sous la forme « Je ressens ceci… »
le registre des opinions : on exprime une interprétation, une métaphore, une conception de la réalité, c’est le cas d’un jugement, d’une appréciation de valeur.

Certains de ces registres sont des facteurs clefs pour une bonne communication. Mais ce n’est pas le cas de tous ces registres.

Le registre factuel peut être utilisé pour poser un problème, décrire une situation. Il est utile pour décrire une vision qui doit être partagée avec autrui. La puissance du factuel, c’est qu’il permet un consensus dans tous les cas. C’est souvent un registre utilisé en introduction, pour « poser le problème ».

Le registre des émotions est très utile aussi car il permet de donner du feedback sur votre état à autrui. Nos émotions exprimées permettent à l’autre de comprendre nos réactions, et si ce dernier peut les comprendre, il pourra aussi s’adapter pour améliorer les choses. Le registre de l’émotion est aussi très utile car il est « incontestable » : si vous ressentez de la colère, vous dites « Je suis en colère », personne ne pourra le contester. Par contre si vous criez « Tu n’es qu’un abruti ! », on pourra deviner que vous êtes en colère mais le dialogue risque de tourner au conflit ! Ce registre permet t’interpeller son collaborateur sur les conséquences de ses actes, plutôt que sur ses actes seuls. On passe d’un discours « Tu… » à un discours « Je… ».

Le registre des opinions doit être utilisé avec beaucoup de précaution. Notre interprétation des choses, nos valeurs, nos principes sont notre richesse intérieure. Ce sont des référentiels uniques d’un individu à l’autre. Mais de l'opinion au jugement il n’y a qu’un pas. Souvent, justement en cas d’émotions, il est très facile d’emprunter des raccourcis et de coller des « étiquettes » aux individus. Exprimer des opinions négatives c'est est un vrai désastre en communication. On parle des fois du « Tu qui tue ». Par exemple, un collaborateur s’est comporté d’une façon qui vous a mis en colère, vous lui dites « Tu aurais pu faire attention ! Tu n’es pas très doué !». Si vous dites « Je pensais que tu devais faire ceci : tu viens de faire cela : je suis plutôt déçu par ce que tu viens de faire, pourrait-on en discuter ? », il s’agit d’une démarche factuelle avec un feedback sur son émotion, c’est plus constructif et ça évite de « rabaisser » inutilement son collaborateur.

Les registres des faits et des émotions nous aident en fait à travailler notre écoute : au lieu de « juger » , on essaye avant tout d’apprendre à mieux connaître son collaborateur. Il en résulte que la relation avec autrui s'améliore, et le travail en équipe s’en trouve lui aussi grandement amélioré. Pour le plus grand bien de tous.

Core Protocols

2008-10-13T04:11:00.000-07:00

La première fois que j’ai entendu ce terme c’était à Paris aux XP-Days, en mai dernier, en déjeunant avec Olivier Albiez. J’ai ensuite lu la traduction française de Gery Derbier des Core Protocols, tirés du livre des époux McCarthy (Software for your Head). A ce jour, je suis persuadé que les Core Protocols sont des outils très puissants pour aider un groupe à devenir une vraie équipe. Ces outils sont le fruit d’observations et d’améliorations à partir de vraies expériences en équipe (bootcamp). Cela explique pourquoi les Core Protocols évoluent avec le temps.

En introduction, les auteurs soulignent que pour constituer une équipe performante, il faut la conjugaison des trois facteurs suivants

la présence des membres de l’équipe (savoir qui est dans l’équipe)
une décision (objectif) qui a l’adhésion totale de l’équipe
l’alignement de chaque membre de l’équipe avec l’objectif commun

On constate que les thèmes abordés ici vont de l’intelligence du groupe au développement interpersonnel. Les époux McCarthy nous donnent des outils pour travailler sur ces trois axes. Par exemple, l’outil « Décider » est un outil qui permet à une équipe de décider à l’unanimité. Un autre outil « Contrôle d’intention » permet d’éclaircir les actions d’un membre de l’équipe qui ne serait pas bien comprises par un autre membre.

Toutefois, j’ai l’impression que ce genre de techniques ne passent pas bien dans notre pays. Nous baignons peut-être dans une culture qui n’incite pas les gens à parler profondément, et pire, qui fait se sentir les gens fautifs si ils révèlent leurs émotions en groupe. Nous sommes extrêmement focalisés sur les domaines de l’action, des tâches, des processus et tellement peu sur ceux de la communication.

Pour en savoir plus, je vous invite à lire la version française(*) pour vous faire votre propre opinion. Pour information, Géry Derbier animera des sessions à l’Agile Tour 2008 de Valence le 23 octobre prochain !

(*) Il s'agit d'une version assez ancienne. Si vous voulez une version plus récente, merci de me contacter.

Scrum et XP depuis les tranchées

2008-10-12T15:40:00.000-07:00

Si vous ne connaissez pas le livre "Scrum and XP from the Trenches" de Henrik Kniberg, vous avez deux options:

soit vous vous précipitez sur InfoQ pour le télécharger et vous le lisez en anglais
soit vous attendez quelques semaines et vous l'aurez en français dans le texte

Nous sommes quelques uns (Guillaume Mathias, Bruno Orsier et Christophe Bunn) à travailler sur sa traduction et j'espère que nous toucherons bientôt au but. Ce joyaux est une mine d'or pour la communauté agile! Des tonnes de conseils pragmatiques, du gros bon sens, bref c'est du très lourd. Il vaut amplement les quelques nuits passées à sa traduction et les relectures. Promis, on va faire le maximum pour vous le donner le plus vite possible... surtout qu'en ce moment, je crois que je suis le "bottleneck" de l'équipe avec le dernier chapitre dans ma "todo list" ;-)

Agilité dans les Arbres

2008-10-02T23:21:00.000-07:00

Bon, voici la vraie histoire à propos de l’accrobranche, celle qui souleva la risée de mes collègues l’année passée : comment je me suis cassé la cheville sur un parcours d’accrobranche.

L’histoire commence quelques mois avant l’accident, époque où je suis allé faire de l’accrobranche plusieurs fois dans un parc (disons le parc A) avec ma fille. Notez que ma femme n’était pas présente.

Le jour de l’accident, nous sommes allé en famille (femme, enfants, cousins, etc… ) dans un autre parc (disons le parc B). Comme dans chaque parc d’accrobranche, il est obligatoire d’être briefé au démarrage sur les consignes de sécurité par un responsable du site. Sûr de moi, ayant déjà pratiqué, je demande si je peux déroger à la règle et si ma femme pourra me passer son baudrier pour que je puisse profiter moi-aussi des sensations. La responsable accepte, précisant que c’est une mesure vraiment exceptionnelle.

Juste avant la fermeture du parc, il se met à pleuvoir et il est temps de rentrer. Je n’avais pas encore profité du parc et ma femme propose que j’aille me faire plaisir avec la grande tyrolienne de 200 mètre de long qui descend le long d’un pré. J’hésite car l’envie n’est pas au rendez-vous mais elle insiste. J’enfile donc le baudrier et me jette sur la tyrolienne…

A mi-parcours du câble, je devine que rien ne pourra me freiner et je vais probablement m’écraser sur la plateforme d’accueil 100 mètres plus loin… au même moment je devine que j’ai du raté quelque chose, que les tyroliennes du parc B sont différentes de celles du parc A… je n'arrive pas à comprendre pourquoi rien ne me freine… je me souviens, dans le parc A, les câbles sont assez lâches pour que les gens soient ralentis et arrivent en douceur sur les plateformes… Eurêka ! Je réalise qu’ici, dans le parc B, on ne peut pas se lancer à fond, il faut probablement maitriser sa vitesse à l’aide de ses mains en serrant le câble… d’ailleurs j’avais bien lu le panneau « Attention, maitriser votre vitesse ! » à l’entrée de la tyrolienne... mais j’ignorai que ça voulait dire, « svp, ne dépassez pas les 3 km/heure ! »… j’étais loin d’imaginer que les règles étaient si différentes d’un parc à un autre… L’arbre qui se rapproche de moi à vive allure vient confirmer mes craintes et je fini la course avec un grand « crac » dans la cheville gauche, au moment où mes pieds heurtent le gros matelas qui entoure l’arbre. Comme j'arrive à me mettre debout, que je suis encore vivant, j'arrive à me rassurer, ça aurait pu être bien pire ;-)

Tout cela a été le résultat de 3 causes conjuguées :

ma femme n’avait jamais été dans le parc A, sinon elle m’aurait mis en garde sur la différence de système des deux parcs
il y a une différence entre les 2 parcs : dans le parc A, on peut se lancer, mais pas dans le B (En 2008, une loi oblige tous les parcs à avoir des dispositifs de sécurité pour éviter ce genre d’accident)
je n’ai pas suivi les règles du parc, c'est mal! Je n’ai pas assisté au briefing du départ... promis je ne le ferai plus!

Il s’en ait suivi un plâtre, puis une petite complication qui dure encore, et surtout des blagues internes sur mon agilité dans les arbres ;-)

Une petite pensée tout de même pour mon cousin, resté suspendu au bout d’une corde, à plusieurs mettre du sol, pendant des dizaines de minutes, pendant que tous les responsables du parc étaient occupé à me faire évacuer vers le CHU ;-)

Team Building

2008-10-02T02:56:00.000-07:00

J’aime beaucoup cette réponse à la question « Comment fait-on du Team Building ? » relevée sur StackOverflow. Il s’agit du témoignage d’un manager d’équipes de développeurs. La transformation d’un «groupe d’individu » vers une « vrai équipe » repose sur certaines pratiques dont il donne une liste des plus importantes selon lui :

Vous vous occupez de PERSONNES, pas de machines ni d’esclaves.
C’est votre responsabilité de transformer ce groupe en équipe.
Au commencement vous devriez donner les premières étapes (Voir The Pragmatic Programmer, Chapter 1, Section 3: "Stone Soup and Boiled Frogs", => être un catalyseur du changement)
Vous ETES un exemple à suivre pour eux.
Le respect des membres est un « MUST HAVE », et ça commence par vous. Vous devez respecter chaque personne dans l’équipe, et vous assurez que tous les membres se respectent mutuellement.
Tous les membres d’une équipe font des erreurs (vous y compris).
Si vous faites une erreur, vous DEVEZ la reconnaître en public avec vos équipes, et dire comment vous allez la réparer.
Si vous voulez blâmer une personne, faites-le en privé. Si vous avez quelqu’un à féliciter, FAITES-LE publiquement au sein de l’entreprise avec les autres membres d’équipe.
Quand vous parlez à votre chef, rappelez-vous que le travail a été fait par vous ET par votre équipe. Vous ne devez pas en assumer seul tout le mérite.
N’embêtez pas votre équipe avec les problèmes du projet. Vous devez toujours les protéger des problèmes extérieurs. C’est votre responsabilité.
Si vous devez blâmer l’équipe, faites-le avec respect ! Peut-être que l’équipe a échoué à cause de vous, vous devez analyser la situation avec soin (peut-être avec eux).
Vous n’êtes pas leur mère.
Après un dur travail à forte pression pour fournir quelque chose, donner une pause aux membres de l’équipe les plus affectés.
Et le plus important de mon point de vue : essayer de très bien connaître chaque membre de l’équipe : leur personnalité, problèmes, peurs, passe-temps, etc.. Cela aide à prendre vos décisions. Exemple : un membre de l’équipe qui a un ou 2 enfants se "gère" de façon différente de celui qui est célibataire vivant dans un petit appartement.
Cela prend du temps pour construire une équipe, ne vous attendez pas à en avoir une en quelques semaines.

Stackoverflow

2008-10-01T00:03:00.001-07:00

Les deux très célèbres bloggeurs Jeff Atwood et Joel Spolsky ont donné naissance il y a peu à un site collaboratif d’entraide pour développeurs appelé Stackoverflow. Basé sur des questions/réponses, il est 100% gratuit. Il est doté d’un système de votations, de badges et de réputation, ce qui permet de trouver efficacement l’information pertinente. Je l’ai testé sur une question sans réponse après qqs heures de recherche sur la toile et j’ai eu une réponse assez intéressante en 10 minutes. A noter que ce concept « question/réponse » est très proche de celui de Yahoo Answers.

Architecture Agile

2008-09-22T00:52:00.000-07:00

Dans le contexte d'améliorer le travail sur l'architecture d'un projet multi-équipe, je suis tombé sur l'article Agile Architecture : Strategies for Scaling Agile Development de Scott W. Ambler. A sa lecture, j'ai pu relier les mises en gardes de l'auteur avec l'organisation de notre "Groupe Architecture" (dont personne n'est vraiment satisfait). J'espère que ses bons conseils nous feront avancer!

En introduction, Scott insiste sur les 3 points suivants:

Humilité : au sein d'un projet, la valeur d'une personne ne dépend pas de sa fonction. Un architecte ne doit pas se mettre (ou être mis) sur un piédestal.
Tour d'ivoire : il ne fait pas créer la tour d'ivoire des architectures. Au contraire, ces derniers doivent être présents sur le terrain, au sein des équipes.
Tout système a une architecture : il faut avoir conscience que tout logiciel a une architecture. Le travail sur cette dernière permet de maintenir une vision commune et un partage collectif du code (collective code ownership)

Ensuite, il donne ses conseils et les bonnes pratiques suivantes:

Architect Owner : les parties prenantes du projet (propriétaire du produit, représentant du client, etc..) ne travaillent pas sur l'architecture mais sur les exigences. Elles ne peuvent donc pas coordonner le travail sur ce sujet. C'est pour cette raison, qu'il faut un rôle de Architect Owner qui aura la responsabilité de faciliter le travail sur l'architecture du produit. Attention, ce n'est pas son rôle de décider, mais plutôt d'animer l'équipe des architectes du projet.
L'équipe d'architectes : si il y a 10 personnes dans un projet, Scott suggère que les 10 soient aussi l'équipe d'architectes. Sinon, en général, 1 ou 2 personnes de chaque endossent le rôle d'architecte. Attention, il ne s'agit pas d'une équipe comme les autres : chaque architecte travaille dans son équipe: il est au service de celle-ci est agi comme un consultant en architecture. Son rôle est aussi de communiquer l'architecture vers les parties prenantes du projet. Il est bon que ce ne soit pas toujours les même personnes qui soient architectes, bien que ce rôle requiert d'avoir "de la bouteille".
Architecture dirigée par les exigences : les exigences viennent avant tout des parties prenantes et non des développeurs! Les aspects métiers doivent être confiés à des utilisateurs, à leurs managers, etc.. Une erreur classique consiste à ignorer certains aspects métier qui ont un fort impact sur l'architecture du produit : par exemple un environnement régulé par un standard, des règles métiers de déploiement. Parler avec les bonnes personnes permet d'économiser beaucoup de temps.
Modéliser l'Architecture : ici, pas de dictat pout tel ou tel type de diagramme UML! Il faut choisir le support qui apportera le plus de valeur aux équipes, et pas plus. Pas besoin de documentation formelle si des dessins sur tableaux suffisent.
Voyager léger (travel light) : plutôt que de documenter exhaustivement l'architecture, en expliquer plutôt ses limites, les zones critiques, les problèmes, etc..
Eprouver l'architecture : la seule façon d'éprouver une conception, c'est de l'implémenter! Faire alors des prototypes afin de vérifier tôt dans le projet certains choix : de cette façon, on réduit les risques de découvrir qu'une architecture ne tiendra pas la route au bout de 6 mois d'implémentation.
Communiquer l'architecture : l'affichage des documents d'architecture est public. Une visibilité extrême permet d'obtenir des feedbacks rapides et nombreux. les architectes communiquent aux équipes mais aussi aux parties prenantes. L'objectif n'est pas le même dans les deux cas et la façon de faire sera différente. Pour les parties prenantes, penser à adapter les informations (pas de détails) dans un contexte compréhensible afin de donner confiance et susciter une implication de ces dernières dans le projet.
Penser au futur mais ne pas en faire plus : avant tout, penser YAGNI (you ain't gonna need it anyway). Ne pas tenir compte des exigences futures, sauf si elle ont de très grandes chances de survenir : on parle alors ici de cas de changement (change case). On doit travailler seulement sur les besoins du moment, mais il arrive que les cas de changement nous orientent entre plusieurs alternatives, ce qui est une bonne chose. Attention, là aussi, la priorité entre les différents cas de changement est définie par les parties prenantes.
Approche multi-vue : Scott nous conseille de travailler sur un espace à deux axes, où le type de vue (stockage, réseau, déploiement...) et les préoccupations (qualité, performance, robustesse, etc..) sont chacun des deux axes. Il en résulte que le travail des architectes concerne un très large spectre de problèmes et les compétences de ceux-ci doivent se généraliser à plusieurs domaines.

En guide le conclusion, Scott compare les pratiques traditionnelles de gestion de l'architecture à celles dites agiles dans le tableau ci-dessous:

Pratique traditionnelle	Pratique Agile
Les architectes sont tenus en haute estime et sont souvent placés sur un piédestal	Les architecte agiles ont l’humilité d’admettre qu’ils ne marchent pas sur l’eau
Les architectes sont trop occupés pour se salir les mains avec le développement	Les architecte agiles sont des membres actifs des équipes de développement, codant du logiciel et agissant comme des consultants en architecture au service de l’équipe
Les modèles d’architecture sont robustes de telle sorte qu’ils satisferont les exigences futures des clients	Les architecte agiles ont l’humilité d’admettre qu’ils ne peuvent pas prédire le futur et, au lieu de cela ils ont le courage de croire qu’ils pourront résoudre les problèmes de demain, demain (pas aujourd'hui)
L’objectif est de développer une architecture détaillée tôt dans le projet	Vous faites évoluer votre architecture de façon incrémentale et itérative, autorisant cette dernière à émerger avec le temps
Des modèles d’architecture bien documentés font partie des exigences	Voyager léger et se concentrer sur les diagrammes de navigation qui donne une vue d’ensemble de l’architecture, en documentant juste ce qu’il faut pour communiquer à votre audience
Les Modèles d’architecture sont communiqués seulement quand ils sont « appropriés à une consommation du public »	Les modèles d’architecture sont affichés publiquement, même quand il y a du travail en cours, afin de susciter des retours de la part des autres
Les revues d’architectures sont tenues pour valider les modèles avant qu’ils soient utilisés	L’architecture est éprouvée à travers des expérimentations concrètes