Agilité et organisation de GN — partie 1

Introduction

Je participe à des projets informatiques depuis quelques années. Dans ce cadre, j’ai été séduit par les méthodes agiles. En parallèle, je pratique et organise des GNs depuis au moins autant d’années.

En partant des postulats :

  • Organiser un GN est un projet, tout comme la conception d’un programme
  • Tous deux partagent des mêmes contraintes : des clients attendent la réalisation du projet, prévu à une date fixée. Et tous deux partagent le même constat : le public est rarement complètement satisfait lors de la publication du résultat du travail fourni.
  • Les méthodes agiles tendent à réduire l’insatisfaction client

Je vous propose d’explorer la piste suivante : comment les méthodes agiles peuvent-elles nous aider à mieux organiser un GN ? J’aborderai cette réflexion à la lueur de différents éléments-clés de l’agilité.

Sens commun

Afin de faciliter la suite de la lecture, convenons d’un vocabulaire commun, afin d’en faciliter le sens.

  • Client : entité demandant, explicitement ou non, à l’équipe de réaliser un projet. Puisque demandeur, le client juge si la réalisation correspond à ses attentes. D’autant que si le client a investi de l’argent et/ou des ressources, il sera légitimé dans son rôle de critique.
  • Equipe : entité réalisant le projet.

Effet tunnel et itérations

L’effet dit “tunnel” se décrit comme suit : après avoir contractualisé une commande, l’équipe se met au travail, et ne partage aucune information sur l’évolution de son travail, jusqu’au moment fatidique d’exposer la réalisation du projet au client. Plus ce délai sera long, plus l’attente du client, et, souvent, par voie de conséquence, affûtera les exigences du client.

Par exemple, il a fallu au grand public attendre 6 ans pour passer de Windows XP à Windows Vista. Et pour quelles critiques en retour ! Nombre d’utilisateurs ont préféré revenir à la précédente version.

Afin de casser cet effet, l’agilité préconise d’itérer : découper la réalisation de son projet, afin de soumettre au plus tôt le réalisé, récolter les critiques et enrichir le projet de ces critiques. En d’autres termes, accélérer au maximum des possibles le cycle vertueux PDCA. Ainsi, la méthodologie SCRUM incite à une durée d’itération de 2 semaines, en terminant par une présentation (démo) au client final. Cela nécessite donc de revoir son travail, puisqu’à la fin de l’itération, l’équipe doit délivrer un produit, c’est-à-dire un élément pouvant être manipulé par le client.

Reprendre ce principe à l’organisation de GN parait être une belle intention : noble mais irreproductible. En effet, comment exposer une partie du travail alors que tout est imbriqué (règles de jeu, histoires, costumes, décors, logistique…) ? D’autant que si nous construisons un jeu à secrets, toute révélation évente le secret, l’effet de surprise souhaité et par conséquent, l‘intensité du projet.

Pour répondre à cette question, il nous faut davantage creuser les vertus de l’itération.

Fail to Win

A la fin d’une itération, il s’agit donc de faire tester par le client l’avancée de notre projet, afin d’en récolter des critiques (positives ou négatives). Nous récoltons des indices qui soit, nous donnent confiance dans ce que nous réalisons, soit nous permettent de rectifier le tir, afin de parfaire le projet. Par là, l’agilité tend à se confronter au client le plus souvent, et ainsi multiplier les échecs, afin d’en retirer les leçons pour mieux faire les prochaines fois.

L’échec n’étant guère plaisant pour l’équipe, il est donc important de créer une atmosphère bienveillante à cet égard. L’itération permet de la cultiver : à réduire le temps avant exposition, le client se fait moins exigeant et plus compréhensif. Surtout si l’équipe construit son discours en incluant le client au projet, et en ne reléguant pas juste au rang de juge final (ses critiques sont part du projet, et ne sont plus celles qui donnent vie ou mort au projet). Un client impliqué devient donc une ressource supplémentaire à la réalisation, et plus un obstacle.

Dans cette philosophie, il me parait plus aisé d’intégrer les itérations à l’organisation du projet : en tant qu’organisateur, il est nécessaire de faire expérimenter des concepts de mon GN, sans pour autant leur dévoiler la totale ampleur du projet-cible. Je puis organiser des ateliers-costumes, afin de les sensibiliser à l’approche visuelle. Ou animer des ateliers-règles, afin de leur faire expérimenter des règles nouvelles, envisager leurs écueils et la facilité d’assimilation. Ou enfin, créer un mini-GN, à l’image de celui que l’on souhaite concevoir ; ce dernier cas de figure permet de répondre à l’énigme “comment tester l’effet de surprise de mon secret sans l’éventer”.

J’ai vécu plusieurs riches expériences de ces “itérations” :

Conclusion

L’itération n’est pas un phénomène nouveau en GN. Nous parlions déjà de “workshop” ou “atelier pré-gn”. Je pense néanmoins que les organisateurs devraient avoir recours de façon + récurrente à ce genre de pratiques. A multiplier ces ateliers, afin de parfaire et co-construire le jeu auxquels tous vont participer.