mardi 27 octobre 2009

Albums Photo Agile Tour


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

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.

mardi 15 septembre 2009

Premier BarCamp à Grenoble

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

mardi 8 septembre 2009

Agile Tour Grenoble 2009, c parti!



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:
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 !

vendredi 14 août 2009

XP-Days Paris 2009

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!!!

mercredi 1 juillet 2009

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

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?

mercredi 17 juin 2009

Lecon apprise n°2 - Adapter la structure


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

jeudi 11 juin 2009

Leçon apprise n°1 - Transition en douceur

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 ;-)

lundi 11 mai 2009

Le lycée collaboratif existe, depuis 1982

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?

vendredi 17 avril 2009

Une question de confiance


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!

jeudi 19 mars 2009

Vers une Administration Agile?


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 ;-)

mercredi 18 mars 2009

Esprit Agile à Marseille

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 ;-)

mardi 10 mars 2009

Approches Agiles dans les grandes entreprises

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!

mercredi 18 février 2009

Esprit Agile


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...

dimanche 8 février 2009

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


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...

lundi 2 février 2009

Le CARA à la soirée Agile Alliance


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!

mercredi 21 janvier 2009

Le mythe de l'auto-organisation?

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?

dimanche 18 janvier 2009

Première formation CSM à Grenoble!

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).

dimanche 11 janvier 2009

Groupe des Utilisateurs Français de Scrum


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.