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