Temps de lecture : 8 min.

La conférence Agile France de l’année 2010 (appelée les années précédentes XP Days France) s’est déroulée le 31 mai et le 1er juin. Comme l’année dernière, elle avait lieu dans le cadre champêtre du Bois de Vincennes, précisément dans le Chalet de la Porte Jaune. D’ailleurs, il était tout à fait possible de faire, entre 2 sessions, un peu de barque sur le Lac des Minimes… mais revenons au sujet.

Sur deux journées, sont donc attendus 300 visiteurs pour 73 sessions tournées autour de l’agilité en général. Cette conférence francophone attire des gens de toute la France et de tout horizon. Je vais vous présenter sur deux articles les sessions auxquelles j’ai assistées. Cette article porte sur la première journée.

Je vais vous détailler la keynote plus particulièrement. Les autres sessions seront uniquement résumées. Le but de cet article n’est pas de faire un compte-rendu exhaustif, mais plutôt de vous donner un aperçu de tous les sujets abordés dans cette conférence.

J’ai essayé de classer les sessions en 3 catégories :

• Modèle : Il s’agit de la présentation d’un concept généralement issu de l’observation. Les modèles ont pour vocation de s’appliquer à l’ensemble de la population. La mise en pratique d’un modèle n’est pas toujours évidente à imaginer.
• Bonnes pratiques : Partage de connaissances généralement admises comme étant bonnes. L’application des bonnes pratiques est immédiates si on connait le sujet traité.
• Retour d’expérience : Des personnes nous font part de la manière dont ils ont mis en pratique une méthode, une technologie.

9h00 : Programmation Neuro Linguistique (PNL) et Agile : les yeux, les oreilles et les sensations

Keynote de Bruno Sbille

Typologie : modèle

Après une petite présentation générale de la part de l’organisation, une keynote sur la PNL (ne pas confondre avec le PNL en finance) est présenté par Bruno Sbille. Dans la grande salle de 300 personnes, Bruno, à travers son expérience sur l’agilité et de ScrumMaster, va nous présenter cette branche de la psychologie qu’est la PNL, et va ensuite nous parlé de VAK.

PNL : Programmation Neuro Linguistique

La PNL est une branche récente de la psychologie. Elle a été inventée dans les années 70. Les principes de la PNL sont les suivants :

• Observation des compétences des personnes de talents
• Déduire des structures communes à partir de ces observations
• Construire des modèles à partir des structures communes
• Utiliser les modèles

Bruno donne plusieurs exemples d’applications de la PNL, notamment Walt Disney qui lors des réunions qu’il organisait, n’hésitait pas à inviter tous les employés (et pas seulement les gens concernés), afin d’avoir le maximum de compétences à disposition.

VAK : Visuel, Auditif, Kinesthesique

Chaque personne utilise un canal de communication principal pour interagir avec d’autres personnes. Ces canaux sont au nombre de cinq, et font référence aux cinq sens :

• V : Visuel
• A : Auditif
• K : Kinesthésique
• O : Odorat
• G : Goût

La PNL regroupe les trois derniers sens au sein d’un unique canal : le canal kinesthésique.

Pour connaître quel est son canal prioritaire, Bruno demande à l’auditoire de repenser à un bon moment du passé, par un exemple un anniversaire où l’on s’est bien amusé. Lorsque chacun d’entre nous a fini de se remémorer ce bon moment, Bruno nous demande l’idée qui est venue en premier. S’il s’agit plutôt du discours qui a été fait lors de cet anniversaire, alors on est plutôt auditif. Si c’est le cadeau reçu lors de l’anniversaire qui ressort dans les pensées, alors on est plutôt visuel. Si on se souvient plutôt de l’ambiance générale, alors on est plutôt kinesthésique.

Ensuite, Bruno nous donne des indices pour repérer quel est le canal de communication prioritaire de nos interlocuteurs, notamment pour les membres de notre équipe :

• Une personne auditive parle beaucoup pour exprimer ses idées, même si on les a compris. Elle utilise des expressions du type : “On s’était dit quoi à la dernière réunion déjà ??”. Ce canal est très utilisé d’après Bruno
• Une personne kinesthésique n’entrera pas forcément en contact avec les gens, car c’est un sujet tabou dans les entreprises. En revanche, elle sera attachée aux valeurs que véhicule la société dans laquelle elle travaille. Elle utilise des expressions du type : ” Tu la sens comment cette réunion ?”. Pour elle, c’est un problème si on prend sa place sans lui demander.
• Une personne visuelle a besoin de dessins pour comprendre les choses. C’est un canal qui véhicule des idées puissantes. Les problèmes sont plus facilement identifiables s’ils sont montrés via un dessin.

Toute cette théorie est utile et utilisable dans le contexte professionnel afin d’identifier son propre canal, ainsi que celui de chacun des membres de l’équipe.

Les applications quotidiennes sont très concrètes :

• Se synchroniser sur le canal de communication de son interlocuteur (exemple : le lors du daily scrum qui fait intervenir les 3 canaux)
• Donner de la reconnaissance à quelqu’un en utilisant le bon canal
• l’IPhone est un succès car son interface utilise les 3 canaux de communication

Triangle dramatique

Triangle Dramatique de Karpman

Le triangle dramatique de Karpman représente les rôles que chacun d’entre nous sommes amenés à jouer dans notre milieu professionnel. Ces rôles se retrouvent chez les gens que l’on côtoie tous les jours et se manifestent de différentes manières :

• Le persécuteur est méchant. Il critique, mais cela peut être sournois, et peut affecter une personne sans qu’elle s’en rende compte
• La victime trouve la vie trop dure. Elle est poursuivie par des déboires. Elle a tendance à se dédouaner de ses fautes. C’est une personne difficile à supporter et qui peut apporter de l’énervement dans l’équipe.
• Le sauveur semble avoir le beau rôle. Il est là pour sauver les mauvaises situations. Il va trouver des problèmes à régler même si on ne lui a rien demandé. Il est intrusif.

Chaque personne y trouve son compte en jouant un de ces rôles. Bruno nous expose donc quels sont les besoins et les bénéfices à jouer ces rôles :

• Le persécuteur a besoin d’un prétexte et d’une victime. Il obtient en bénéfice un sentiment de toute puissance et cela lui permet d’évacuer sa frustration
• La victime a besoin d’un persécuteur où elle crée un contexte défavorable. Elle obtient en bénéfice de la pitié et de la sympathie.
• Le sauveur a besoin d’une victime. Il obtient en bénéfice de la reconnaissance, et cela lui permet de ne pas s’occuper de ses problèmes.

Les effets pour le travail en équipe sont évidemment pervers. Il faut donc que personne ne joue ces rôles, d’après Bruno. Différents moyens sont possible pour que chacun puisse sortir de ces rôles.

Conclusion

Cette keynote a été l’occasion pour moi d’aborder un pan complet de la psychologie que je ne connaissais pas. Malgré tout, cela apporte une dimension sur la communication au sein de l’équipe qu’il faut essayer de s’approprier de manière à mieux faire passer le message que l’on souhaite faire passer.

La présentation peut être revue sur slideshare : http://www.slideshare.net/brunosbille/prs-agile-france2010bsbv3-4379231

Une ancienne présentation de Bruno sur le sujet : http://www.slideshare.net/brunosbille/sug-pres-bsb-soiree-anniversaire-v3-final-3628800

10h00 : La revue de code: agile, lean et indispensable !

par Lucian Precup

Typologie : bonnes pratiques

A travers sa présentation, Lucian à pour objectif de nous persuader que la revue de code est une étape clé dans la phase de développement, et que cette revue n’est pas qu’une étape rébarbative et manuelle puisqu’elle peut se faire assister par des outils.

Commençons par définir ce qu’est la revue de code : il s’agit d’une inspection systématique du code source par une autre personne que celle qui l’a écrit. Cette pratique a été démocratisée avec les méthodes agiles avec le pair programming notamment. La revue de code a différents buts pour l’équipe. Elle permet de trouver les bugs fait par l’auteur, et améliore donc la qualité du logiciel. De plus, cela améliore les compétences de développement de chacun, en apprenant les bonnes pratiques et en les diffusant. Les revue de code peuvent être formelles ou non, et peuvent se faire pré ou post-commit.

Voici une petite liste non exhaustive des nombreux avantages de la revue de code :

• Détecter les bugs
• Promouvoir l’apprentissage
• Former les nouveaux membres de l’équipe
• Promouvoir le partage
• Rendre le code plus maintenable en y ajoutant plus de documentation par exemple
• Trouver de meilleures solutions techniques

La revue de code, comme toute pratique un peu moderne, a ses détracteurs. Voici quelques idées reçues que Lucian nous présente :

• La revue de code augmente la durée des développement : Oui la phase de développement est plus longue à cause de la revue de code, et des éventuels bugs à corriger que la revue de code à fait émerger. Mais la phase de recette est bien moins longue car l’application gagne en fiabilité. Cela entraîne moins de bug en production. Au final, on passe moins de temps en recette et l’application gagne en qualité. Des études citées par Lucian indiquent que 60 à 70% des bugs sont trouvés lors de la revue de code.
• Peut-on automatiser la revue ? Une partie peut être faite par des outils. Ces outils peuvent indiquer des patterns à éviter, et sortir des métriques sur le code. Mais rien ne remplace le partage des connaissance que la revue apporte.
• Il faut donc faire du pair programming ? C’est très efficace, mais bien plus coûteux qu’une revue classique.

11h30 : Comment j’ai remplacé 30% de mes développeurs en adoptant l’agilité

par Jean-Laurent de Morlhon

Typologie : retour d’expérience

Sous ce titre original, se cache un retour d’expérience de l’entreprise Vidal Software sur la mise en place de Scrum au sein de leurs équipe. Ce retour d’expérience était surtout un échange entre nous et les orateurs.

Vidal a dans un premier temps expliqué l’évolution de leur Scrum Board. Il y en a eu trois versions différentes. Chaque nouvelle version a ajouté une colonne : par exemple la V3 a ajouté une colonne pour indiquer qu’une user story est validée et testée.

Ensuite Vidal nous as parlé de la rétrospective. Pendant les six premiers mois, il n’y avait pas de rétrospective. Une fois mise en place, une des tâches que l’équipe faisait lors de la rétrospective, était de noter l’équipe sur un ensemble de critères qu’ils avaient choisis. Cela permettait à chaque rétrospective de voir l’évolution de l’équipe, et aussi de déterminer les point noirs à corriger.

14h30 : Vaincre le Plouf

par Guillaume Duquesnay

Typologie : modèle

Cette présentation fut la plus originale dans sa forme de celles auxquelles j’ai assisté. Guillaume joue presque une pièce de théâtre lorsqu’il nous présente son plouf.

Le plouf est ce phénomène qui nous empêche d’accomplir des choses que l’on doit faire. C’est cette force mystique qui nous fait toujours remettre les choses au lendemain. Le plouf s’applique aussi bien au domaine professionnel que personnel.

Guillaume commence par nous donner les grandes caractéristiques du plouf. Certaines des caractéristiques sont son silence, le fait qu’il se répand d’un individu à l’équipe, et qu’il attaque au commencement des projets…. Après avoir caractérisé l’ennemi, Guillaume nous donne les moyens de le vaincre. Ces conseils peuvent paraître simple, mais sont sûrement la clé pour vaincre le plouf. Quelques unes des actions à entreprendre pour éviter le plouf :

• Engager une action pour se rapprocher de l’objectif
• Lors de réunion, commencer le plan d’action définit dès les dernières minutes de la réunion
• Demander les choses directement (de visu), plutôt que d’envoyer un mail, ou de laisser un message répondeur
• S’inspirer des méthodes des équipes du marketing

15h00 : Sortez vos crayons

par Benoit Gantaume

Typologie :  bonnes pratiques

L’objectif de cette présentation est de présenter des idées plus percutantes grâce au dessin. Cette présentation est un bon mélange entre pratique et théorique.

Benoit commence par nous rappeler quels sont les prérequis de la pensée visuelle :

• un crayon
• des yeux
• un cerveau
• une main
• un support

Il continue en nous décrivant les 4 étapes de la pensé visuelle :

1. regarder
2. voir
3. imaginer
4. présenter

Une fois ces prérequis établis, Benoit nous explique des manières de dessiner et de schématiser les pensées que l’on veut exprimer. Par exemple, si on veut dessiner quelque chose qui répond à la question “qui ?”, alors il est bien dessiner un portrait. Si le dessin doit répondre à “Où ?”, il est bien de dessiner une carte. Les règles qu’il donne ne sont pas absolus, et peuvent être contourner en fonction du besoin.

S’en suivent beaucoup d’ateliers en petits groupe, pendant lequel nous devions représenter Scrum en dessin en répondant aux question du style : Qui est scrum ? Où est scrum ? pourquoi scrum ?…

Bilan à mi-conférence

Cette première journée a été l’occasion de rencontrer des professionnels de l’Agile. Leur présentation est l’occasion de chercher les meilleures idées à utiliser tous les jours durant nos projets. Mon but était de trouver des bonnes pratiques afin de faire entrer l’agilité chez mon client où les pratiques agiles sont inexistantes. De bonnes idées me sont parvenues dès ce premier jour. Le deuxième jour ne pouvait s’annoncer qu’excellent !

Bibliographie

Vaincre le plouf : http://vaincre-le-plouf.fr/