Un article de Bruno Orsier    Commentaires fermés

Aujourd’hui j’ai animé un quatrième dojo agile (en interne, contrairement aux dojos du CARA où je participe comme secrétaire ou animateur occasionnel ou simple participant). Dans les dojos internes ma préoccupation principale est toujours de trouver des activités qui puissent intéresser nos utilisateurs embarqués dans les équipes Scrum. Ces  utilisateurs ne savent pas programmer, et je ne peux donc pas me baser sur des activités de programmation pure. Par exemple je ne peux pas utiliser les innombrables vidéos qui comportent plein de code, ce qui réduit beaucoup mes choix. De plus je dois essayer de varier les activités, afin de maintenir l’intérêt des participants. Alors aujourd’hui le programme que j’avais concocté était 1) vidéo « Agile Testing » 2) Exercice d’auto-organisation d’équipe 3) suite du challenge de programmation (le simulateur de fourmis) déjà mentionné dans les billets précédents.

Nous avons en fait commencé par examiner les suggestions de la rétrospective du dojo précédent. Nous faisons systématiquement un débriefing « à chaud » en fin de journée, ainsi qu’une rétrospective « à froid ». La rétrospective est faite grâce à un formulaire sur un site web. Je suis bien conscient que ce n’est pas une rétrospective bien classique, mais ca fonctionne pour le moment et cela ne prend pas beaucoup de temps.

Justement, commencer par examiner les suggestions était une suggestion de la rétrospective précédente. J’espère que vous me suivez toujours…

L’une de ces suggestions était que le travail sur le simulateur de fourmis était devenu très technique, et que les utilisateurs embarqués étaient un peu perdu. En effet vu les difficultés posé par le caractère aléatoire du sujet, nous avions décidé de doubler le générateur par quelque chose que nous puissions contrôler. C’est une étape intéressante et très pédagogique pour former les développeurs (à mon avis), mais là nous avons en effet perdu les utilisateurs… Nous verrons plus bas comment nous avons essayé de corriger le tir.

La vidéo

La première activité était de visionner la vidéo Agile Testing, par Elisabeth Hendrickson (vidéo recommandée par mon collègue Sébastien). Le contenu de cette vidéo n’est pas très nouveau pour nous, après plus de trois ans de pratique des méthodes agiles. Toutefois c’était instructif de voir les méthodes agiles présentées par quelqu’un d’autre qu’un informaticien. Elisabeth Hendrickson vient en effet de la QA et du test, et était d’abord sceptique par rapport à XP, puis a changé d’avis en voyant que cela pouvait résoudre des problèmes traditionnels dans le développement de logiciels. De plus cette vidéo est un bon moyen de travailler l’anglais car elle articule bien et sa présentation est très vivante. L’objectif des dojos internes est d’apprendre dans tous les domaines utiles pour notre métier, et pour nous la maîtrise de l’anglais est indispensable. Comprendre Elisabeth Hendrickson en vidéo est même plus facile que comprendre certains collègues ou clients en téléconférence ! J’envisage donc pour un prochain dojo de trouver une vidéo en anglais sur un sujet inconnu de l’assistance, pour être plus proche de la réalité d’une téléconférence.

La vidéo a été appréciée par nos utilisateurs embarqués (qui ont le même parcours qu’Elisabeth Hendrickson), et qui ont fait remarquer qu’avant Scrum, ils étaient « la quatrième roue du carrosse », et que cela s’était bien amélioré depuis que nous travaillons en Scrum. Cela a plutôt surpris les développeurs qui n’étaient pas très conscients de ces sentiments, et rien que pour cet échange ca valait le coup de voir cette vidéo.

L’exercice d’auto-organisation

Dans les dojos externes je trouve que notre plus grande difficulté est de simplement bien fonctionner en groupe. Ce n’est pas du tout évident. Cela m’a donné l’idée d’un nouvel exercice qui chercherait à mettre en lumière cette difficulté. Je n’ai pas de solution a priori, mais cela me paraît utile de commencer par révéler le problème.

J’ai donc donné au dernier moment un bon article sur le TDD, intitulé Realizing quality improvement through test driven development: results and experiences of four industrial teams (pour information il y a aussi cette vidéo avec l’un des auteurs – mais je ne l’ai pas visionnée, et cela ne faisait pas partie de l’exercice.)

Mes instructions étaient que les participants du dojo (sept personnes) devaient trouver comment s’organiser dans les 75 minutes suivantes afin de faire une présentation de cet article. Cette présentation devait être d’une durée de 15 minutes maximum, et serait faite devant d’autres collègues qui viendraient spécialement pour assister à la présentation.

Mon idée était que toute auto-organisation doit se faire par rapport à un objectif (ici la présentation) mais aussi par rapport à des difficultés ou des risques anticipés (il faut se renforcer là où il y a des risques), j’ai donc d’abord demandé un petit brainstorming pour identifier les difficultés potentielles. Voici quelques difficultés :

• temps limité
• difficulté de travailler en groupe
• risque de se noyer dans des détails
• arriver à comprendre l’ensemble de l’article, même si on se partage le travail
• décider d’un format de présentation (avec PowerPoint ? MindManager ? Tableau blanc ?)
• mots anglais inconnus, difficultés de compréhension
• être capables de répondre aux questions de l’assistance après la présentation

Les participants ont ensuite cherché à identifier plusieurs rôles, afin de se répartir le travail, notamment en binômes (cela afin de réduire les difficultés de compréhension). Parmi les rôles identifiés, ils ont trouvé un rôle de lecteur (lire tout l’article afin d’assurer la cohérence et de répondre aux questions), un rôle de rédacteur (gestion du support de la présentation), des rôles de responsables des divers segments de l’article. Ils ont aussi rapidement convenu d’un plan.

Ils sont ensuite lancés. Et le plan n’a pas fonctionné comme prévu ! D’une part certaines difficultés matérielles (que je n’avais pas anticipées) sont apparues durant les 75 minutes : le seul PC disponible avait Powerpoint 2007 que les participants ne connaissaient pas, il n’y avait pas assez de papier sur le tableau à papier déroulant (comment ca s’appelle déjà, ce machin ?)… D’autre part les participants avaient fortement sous-estimée la partie centrale de l’article, que le binôme responsable n’arrivait pas à lire assez vite ! Le binôme en question râlait dans son coin, pendant que les autres étaient complètement impliqués dans leurs travaux.

Cela a rendu visible qu’ils n’avaient pas identifié un rôle de « facilitateur » (ou de ScrumMaster). J’ai alors temporairement posé ma casquette d’animateur de l’exercice pour jouer celui de facilitateur de l’équipe, en attirant l’attention d’un des membres pas trop occupé (le lecteur « global » – un rôle finalement pas très utile) sur la surcharge du binôme en question. Une autre personne a également pris une part supplémentaire de travail, ce qui a finalement permis de couvrir complètement la partie difficile.

Enfin les membres de l’équipe se sont rendu compte qu’ils n’auraient pas le temps de donner des informations à un rédacteur/présentateur unique, et ils ont dû décider au dernier moment de faire leurs propres supports et leur propre présentation ! Pour se coordonner ils ont réussi à faire une simulation accélérée de la présentation.

Toutes ces difficultés ont finalement bien contribué à l’intérêt de l’exercice en forçant l’équipe a s’adapter. Dans le débriefing, ils ont d’ailleurs constaté que sans l’habitude de travailler ensemble dans des équipes Scrum, ils n’auraient certainement pas réussi à s’adapter aussi bien ! Voilà certainement une grande réussite de notre implémentation de Scrum.

La présentation s’est très bien déroulée et a été jugée intéressante et pertinente par le public (qui n’avait pas lu l’article).

Et vous, connaissez d’autres exercices pour favoriser le travail en groupe ?

Le challenge de programmation

L’après-midi a été ensuite consacré à la suite de notre challenge de programmation. Pour éviter de continuer à perdre nos utilisateurs, nous avons décidé que le problème technique de la doublure de test serait traité à part, et présenté dans le prochain dojo. Nous avons alors pu nous recentrer sur des activités moins techniques, et plus compréhensibles pour nos utilisateurs : construction du terrain de jeux, des fourmis, positionnement de la fourmilière…

La séance a suscité de nombreuses questions des utilisateurs qui souhaitent mieux comprendre le vocabulaire employé par les informaticiens. C’est normal étant donné qu’ils participent à l’élaboration des tests unitaires ! Nous passons donc du temps à expliquer (rapidement) des notions comme classe, méthode, attribut… Un schéma UML a même été employé. Tout cela me paraît positif car cela renforce la compréhension mutuelle entre les membres d’équipe.