Des ateliers participatifs
Prérequis et objectifs
Ce chapitre n’est pas destiné à vous apporter des connaissances théoriques ou à approfondir celles que vous possédez déjà, mais à vous proposer des solutions opérationnelles que vous pouvez utiliser sur le terrain. Il ne comporte donc pas de prérequis ni de validation des acquis.
Introduction
Il existe deux formes de connaissances. La connaissance explicite, qui peut être transmise verbalement à l’oral ou à l’écrit, et la connaissance tacite qui est difficilement transmissible à l’oral.
Si ce concept ne vous semble pas clair, prenez l’exemple des jeux de séduction. Ils sont faiblement basés sur des connaissances explicites et fortement basés sur des connaissances tacites. Une personne très compétente dans ce domaine peut tenter d’expliquer à une autre comment elle doit s’y prendre. Le résultat donne souvent un scénario comique.
Pour échanger certaines connaissances ou informations tacites, une activité commune est souvent plus efficace qu’un échange verbal.
Planning poker
Cet atelier a été imaginé en 2002 par James Grenning. Il arrivait régulièrement que deux développeurs ne soient pas d’accord sur l’estimation du nombre de jours nécessaires pour réaliser une user story. Tout le monde avait conscience de perdre beaucoup de temps en estimations. Une fois, James a fait une expérience, il a demandé à chaque développeur de noter secrètement son estimation personnelle puis il a laissé les deux développeurs échanger entre eux durant plusieurs minutes. Au bout de vingt minutes, il a demandé à tous les participants de redonner leur avis. Les estimations n’avaient quasiment pas changé. Tout le monde a pris conscience qu’ils venaient tous de perdre vingt minutes à faire des prévisions aussi fiables que la météo.
Ce processus a donc été généralisé par cette équipe :
-
Le Product Owner raconte la user story.
-
Chaque développeur note secrètement son évaluation.
-
On compare.
S’il n’y a pas beaucoup de différences, on adopte une valeur moyenne.
S’il y a de gros écarts, le plus faible et le plus fort expliquent rapidement leur approche, l’équipe adopte l’une ou l’autre et réestime immédiatement.
Si l’équipe ne parvient...
Achète-moi une fonctionnalité
Cet atelier est inspiré du planning poker mais à destination des parties prenantes ou des utilisateurs, afin de découvrir la valeur business qu’ils accordent aux différents éléments constituant le Backlog de produit.
Il peut être utilisé dans plusieurs cas afin d’aider le Product Owner à affiner ses estimations de valeurs et à mieux ordonner son Backlog de produit.
Le principe est très simple, le Product Owner commence par décrire l’élément et l’ensemble des participants doit en évaluer la valeur, non pas avec des cartes à jouer, mais avec des billets de banque.
Chacun évalue la valeur de l’élément, et les différences d’estimations permettent d’engager un débat. En fin de cession, le Product Owner ordonne les éléments par ordre croissant de valeur et s’assure que les participants confirment leurs estimations initiales. Si un élément vaut deux ou trois fois plus qu’un autre, cela doit avoir une explication.
Il arrive qu’un même élément ait une valeur différente selon des points de vue métier. Par exemple, une fonctionnalité dédiée au recrutement peut être évaluée à 50 points par l’utilisateur du service commercial alors...
La méthode GROW
Cette méthode publiée en 1992 par John Whitmore est utilisée par de très nombreux coaches pour faire prendre conscience des dissonances entre ce que les participants savent et ce qu’ils mettent réellement en pratique.
Plutôt que de donner des informations visant à tenter de convaincre la personne de modifier son comportement, GROW permet à la personne de comprendre le problème par elle-même, d’en tirer les conclusions et d’adapter son comportement. La solution venant d’elle et non du coach, elle n’a plus besoin d’être persuadée.
GROW est un acronyme mnémotechnique qui signifie Goal, Reality, Obstacles ou Options et Will.
-
Goal : l’objectif ou le but à atteindre. Il doit être clair, et mesurable.
-
Reality : le point de départ, là où nous sommes aujourd’hui.
-
Options ou Obstacles : ce qui nous permet ou nous empêche d’atteindre l’objectif.
-
Way forward : l’ensemble de ce qu’il faut faire, quand il faut le faire, et de la volonté qu’il faut y mettre. Whitmore utilise également les termes What, When, by Who et Will pour illustrer le W de GROW.
GROW commence par la définition de l’objectif. Il est préférable de définir les objectifs dans l’absolu, et de réaliser ensuite clairement...
1-2-4-all
Cet atelier sert à trouver des solutions, faire émerger des idées innovantes, régler à plusieurs un problème… Le principe est très simple : 12 personnes, 12 minutes à l’issue desquelles un concept ou une idée doit émerger.
Destiné à remplacer les interminables réunions de type remue-méninges, cet atelier favorise réellement l’intelligence collective.
Il faut des petites tables pouvant accueillir 4 personnes, et donc 4 chaises par table, mais l’atelier ne durant que quelques minutes il peut également se dérouler sans tables ni chaises.
L’animateur de la réunion pose rapidement un problème à résoudre et lance le chronomètre. Pendant 1 minute, chaque personne isolément cherche une idée. Puis on forme six groupes de deux personnes. Au sein de chaque groupe, les idées sont confrontées pendant 2 minutes. Ensuite, pendant 4 minutes les idées des idées sont échangées par groupes de quatre. La configuration idéale est composée de 12 personnes, il y a donc normalement trois groupes, mais cet atelier peut aussi être réalisé avec 8 ou 16 personnes.
À l’issue de cet échange d’idées par groupes de quatre, tout le monde échange durant les 5 dernières minutes....
Enduis-moi d’erreur
Cet atelier permet aux participants de comprendre l’importance du pilotage d’activité par objectif et l’incidence que peut avoir une suite d’instructions sur le résultat d’une activité complexe. Il est utilisé dans le cadre de formation de managers et par des coaches lors des premiers ateliers de déploiement de l’agilité dans des organisations.
Dans cet exemple, il est demandé aux participants de réaliser les spécifications permettant de faire un bateau en papier, de planifier leur activité en respectant les quatre phases d’un cycle en cascade, recueil des besoins, conception, réalisation et tests. Les participants sont répartis en trois ou quatre groupes de deux à quatre personnes.
L’animateur commence par inviter chaque groupe à donner une estimation du délai qu’il leur faudrait idéalement pour faire un bateau en papier, puis il insiste sur le fait que l’exercice est difficile et que peu d’équipes parviennent à le réaliser correctement dans un délai de 45 minutes, ce qui est parfaitement exact. Pour pimenter un peu l’atelier, il est possible d’indiquer que le groupe qui a terminé en premier ses spécifications remporte la victoire. À condition bien sûr qu’une autre équipe soit en mesure...