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