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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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