Retour sur un atelier Innovation Games chez Palo-IT

C’est suite à un passage sur le stand de Palo-IT au salon Devoxx que je me suis retrouvé à participer à un atelier sur les Innovation Games dans leurs locaux hier soir. Je vous en propose un compte-rendu rapide.

J’avais bien-sûr entendu parler de ce genre de pratique et j’avais même, dans une certaine mesure, déjà l’habitude d’en organier grâce à Scrum au travers des plannings poker et autres rétrospectives. Cependant j’étais très curieux de voir à quel point on pouvait généraliser leur usage. En effet quand il s’agit d’un poker ou d’une rétro, le fait de passer par un jeu ou même de faire appel à un animateur est naturel, tant la pratique de Scrum est très axé sur ces concepts. Mais est-il possible d’utiliser des Innovations Games dans le cadre de réunions critiques et avec des participants qui ne s’y rendent pas dans le but de participer à un atelier ? En tout cas c’était le genre de question que je me posais en arrivant et à laquelle j’ai trouvé des éléments de réponse.

Je passe rapidement sur l’accueil très sympathique et chaleureux que j’ai reçu en arrivant (merci beaucoup, au passage, à l’équipe de Palo-IT et aux autres participants) pour attaquer directement le déroulement de l’atelier.

Après une présentation de quelques minutes sur les Innovation Games, leur intérêt, la littérature et les principaux jeux existant, nous avons constitué trois groupes afin d’expérimenter les suivants :

• Start your day
• Give them a hot tub
• Speed boat

Start your day avait pour but de retracer le déroulement d’une activité de A à Z (une journée, une mission, un projet) et d’identifier des usages potentiels associés à un produit au cours de ce déroulement. Ceci plutôt dans une logique d’identifier des opportunités pour améliorer un produit ou un processus existant.

Give them a hot tub était un jeu axé sur la créativité et permettant de trouver des idées de fonctions innovantes à associer à un produit. Le déroulement du jeu ressemblait beaucoup aux grands principes sur lesquels se basent les formations de Designer (adopter une réflexion créative libérée de toute contrainte, puis la confronter à la réalité).

Je faisais partie du 3ème groupe qui a essayé le jeu Speed boat. Il s’agissait de dessiner un bateau sur un paper-board (l’un des membres du groupe s’est fendu d’un dessin de trimaran plutôt réussi ;-) ) et dessiner des sortes d’ancres en dessous. Le bateau symbolisait la volonté d’atteindre un objectif, en l’occurrence on simulait la situation d’une équipe Scrum qui a de (gros) problèmes d’efficacité. Cette base étant posée, l’animateur a demandé que chaque participant écrive sur des post-it les problèmes qu’il imagine bloquer l’avancement du bateau (et donc en l’occurrence empêcher l’équipe Scrum d’être efficace). A raison d’un post-it par problème, on a tous sorti 5 ou 6 items que l’animateur a ensuite collé un par un sur les lignes symbolisant les ancres du bateau et en les organisant à la fois par gravité (les problèmes les plus bloquants tout en bas) et par typologie (on a fait un groupe pour les problèmes de comportement de l’équipe, un autre pour les problèmes de matériel, un autre pour les problèmes de vétusté du code, etc.).

A ce stade, le paper-board était déjà très intéressant, car il cartographiait les problèmes de façon très claire, permettant de dégager les masses les plus critiques, et avait le mérite d’être le reflet de l’expression de chacun, y compris bien-sûr celle des gens un peu plus timides ou soumis à des pressions qui les auraient empêché de s’exprimer librement.

Suite à cela, on a fait un brainstorming beaucoup plus classique pour évoquer des pistes de solutions à l’oral, les écrire sur des post-it, là encore, et les disposer avec la même logique de regroupement, mais cette fois au dessus du bateau (symbolisant des cerfs-volants ou du vent venant pousser le voilier pour l’aider à avancer…). Les solutions trouvées n’étaient pas très originales (je n’ai pas vraiment trouvé là de vrai catalyseur d’innovation), mais au moins les solutions étaient identifiées collectivement et amendées tout de suite. On imagine bien qu’à postériori la mise en application aurait largement été facilitée par ce côté “construction collective” et aurait reçu un niveau d’engagement très fort.

L’atelier s’est terminé finalement par une petite rétrospective générale. L’occasion de constater que tout le monde avait tiré essentiellement du positif de cette expérience, que le fameux ROTI (Return Of Time-Invested) était très élevé et que chacun se sentait bien inspiré et motivé par la mise en pratique en situation réelle de cette expérience acquise… Ce que j’ai fait dès le lendemain ! :-)

Expérimentation du Speed boat pour résoudre un problème d’organisation

[caption id=”attachment_257" align=”alignright” width=”168"]

Résultat du jeu Speed Boat que j’ai organisé le lendemain pendant une réunion[/caption]

J’avais justement une réunion prévue cet après-midi avec des commerciaux de ma boite et le DSI (qui est mon supérieur direct) pour tenter d’améliorer un problème d’organisation constaté sur certains types de projets.

Comme on en avait discuté la veille, je n’ai pas présenté les choses trop directement en disant que je voulais organiser un atelier (et encore moins un “jeu”, je me suis bien gardé de prononcer ce mot). Je me suis simplement dirigé vers le paper-board dès le début de la réunion, j’ai dessiné un bateau et j’ai proclamé :

On est tous dans le même bateau et notre but est de passer d’un point où notre organisation n’est pas efficace à un point où tout baigne

Je représentait en même temps un point A derrière le bateau et un point B devant, puis j’ajoutais :

Je vous propose de noter les problèmes qui empêchent le bateau d’avancer sur des post-it et nous les confronterons ensuite.

Je leur ai filé des blocs et des stylos que j’avais nonchalamment laissé traîner sur la table et tout le monde a commencé à jouer le jeu spontanément ! Ça a été un vrai succès !

J’ai demandé en sortant leurs impressions aux deux commerciaux : ils étaient ravis et trouvaient que la réunion avait été extrêmement efficace, qu’ils avaient pu exprimer tout leur ressenti et étaient très satisfaits et convaincus que les solutions trouvées allaient porter leurs fruits.

Le DSI, lui a eu une réaction plus mitigée. Quand je l’ai interrogé, il m’a répondu en substance :

Moui… C’était pas mal. On avait besoin de retrouver de la cohésion et ça a bien fonctionné sur ce plan

Comme j’insistais, comprenant qu’il trouvait que ça n’avait pas était si utile que ça sur d’autres plans, il a fini par me répondre :

Les solutions trouvées au final, sont celles que je comptais proposer de toute manière… L’intérêt de l’animation n’a donc été que de donner l’impression qu’on les trouvait tous ensemble… J’aurais autant apprécié arriver, décrire mes solutions et demander à tout le monde de les appliquer…

Chacun pourra se faire sa propre opinion sur la méthode qui aura présenté le plus grand intérêt au final…

En conclusion : cette double expérience m’a convaincu de creuser beaucoup plus le potentiel des Innovation Games. Et même s’il existe des septiques qui peuvent être réfractaires à ce genre de pratique, je retiens la remarque de Xavier Warzee, CTO de Palo-IT :

Je n’arrive plus à faire une réunion sans utiliser ce genre d’animation : on fait 10 fois plus en 40 minutes qu’en 3 heures de réunion classique.

Merci encore Palo-IT ;-)

Si vous voulez creuser vous aussi :

• Un site sur les Innovations Games, qui en liste et en décris beaucoup : http://innovationgames.com/
• Le blog de Palo-IT qui organise régulièrement des barcamps et des ateliers de ce genre : http://palo-it.com/blog/
• Les deux livres de référence évoqués par Cédric Mainguy, le consultant qui a organisé cet atelier :
• Innovation Games: Creating Breakthrough Products Through Collaborative Play
• Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers