(article initialement publié en anglais traduit par l’auteure elle même !)

(Original ici: http://colinepannier.com/2016/01/13/why-is-scrum-so-much-fun-1/)

Scrum fonctionne t-il comme un jeu ?

Ces dernières années, j’ai eu l’occasion d’explorer différentes utilisations et dimensions de Scrum. Sur les projets utilisant Scrum et la philosophie Agile, j’avais le sentiment d’être dans un environnement plus stimulant, je me sentais plus accomplie et enthousiaste. Dans mon équipe, l’ambiance était meilleure, nous étions plus productifs, engagés et, d’une manière générale, beaucoup moins stressés. Pour le dire simplement : travailler sur des projets avec Scrum était fun. J’ai commencé à me demander ce qui faisait qu’un projet était mieux avec Scrum que sans.

Travaillant dans l’industrie du jeu, et constatant chaque jour l’incroyable capactié d’engagement que peut avoir un bon jeu, je me suis demandée :

Et si Scrum fonctionnait aussi bien… parce qu’il était conçu comme un jeu?

Les études comportementales et le game design peuvent nous donner des clés pour comprendre le pouvoir d’engagement de Scrum. Dans son livre de référence Reality is Broken,^[1] la chercheuse et game designer Jane McGonigal identifie 4 caractéristiques que tous les jeux ont en commun :

“Quand on fait abstraction des différents types de jeux et des complexités techniques, on observe que tous les jeux partagent quatre traits caractéristiques: un but, des règles, un système de feedback et une participation volontaire.”

Faisons un parallèle et voyons comment ces 4 critères peuvent s’appliquer à la méthode Scrum.

Première partie : Le But

Il y a des buts à différents niveaux dans Scrum. Il y a le but ultime, qui est la livraison du produit final. Celui-ci n’est pas spécifique à Scrum et existe aussi dans les organisations et méthodes de gestion de projets “traditionnelles”.

Lorsque j’étais chef de projet ou que je participais à ces projets avec des plannings gigantesques et des diagrammes de Gantt détaillés, une des choses que j’ai toujours trouvées frustrantes est que le but semblait toujours si éloigné qu’il était difficile me sentir concernée par le résultat. Les jalons paraissent tels d’énormes montagnes que l’on devait gravir dans une météo incertaine, tout en ignorant ce qu’on allait trouver une fois le sommet atteint — sommet qui, d’ailleurs, paraissait toujours s’éloigner à mesure qu’on pensait s’en approcher.

Un second type de but est ce que nous pouvons appeler les “buts intermédiaires”. Ceux-ci sont bien différents des jalons des projets traditionnels, dans le sens où ils représentent une boucle complète de planning, d’exécution et de livraison.

Scrum a un moyen génial pour rendre le but plus accessible: Les Sprints. Les Sprints sont des périodes de temps prédéfinies pendant lesquelles l’équipe s’engage à remplir un certain nombre d’objectifs atteignables. Chez inaloop games par exemple, nous avons décidé de faire des Sprints de 2 semaines, ce qui nous donne assez de temps pour atteindre 3 objectifs prioritaires et constater des résultats significatifs.

Chaque Sprint est comme un jeu, où le but est de faire une prédiction, la plus précise possible, du nombre de points de vélocité que nous allons atteindre. Le truc est de prédire un nombre de points ambitieux, de façon à battre notre précédent score, mais pas trop ambitieux non plus, parce que nous voulons être capables de l’atteindre.

Scrum modifie le but, qui de “livrer cet énorme projet” devient “faire la prédiction la plus juste possible de ce que nous pouvons livrer dans un laps de temps prédéfini”

Pour prendre une métaphore sportive, nous pourrions dire que les Sprints sont comme des matchs de football, et que le but ultime est d’atteindre le sommet du championnat. A la fin de chaque partie, l’équipe a une idée claire de sa performance et de sa progression dans le classement de la ligue.

Supprimer les Sprints reviendrait à supprimer les matchs de football et à les remplacer par un seul match qu’il faudrait jouer pendant des mois.

En tant que joueur de foot professionnel, il vous faudrait vous réveiller chaque matin et reprendre la partie avec votre équipe pour essayer d’ajouter des points à votre score ; tout en étant encore à des mois de la fin de la saison. Au bout d’un certain temps, vous et votre équipe prendriez le temps de regarder votre score pour voir que vous auriez atteint 274, et tout le monde serait déçu, parce que vous vous imaginiez que vous seriez plus près de votre objectif de 1000 points.

Alors vous auriez droit à un discours de motivation de la part de votre coach, et pendant un certain temps vous seriez de nouveau gonfé à bloc et déterminé à faire mieux. Vous vous lèveriez le matin suivant, bien décidé à courir plus vite et à marquer plus de points. Vous ne voulez pas décevoir votre équipe dans ce match de foot long, ennuyeux et épuisant…

Cela n’a pas l’air très fun, n’est-ce pas ? C’est bien simple : si un but est trop vague ou parait hors de portée, il n’est pas motivant.

Les game designers, qui sont les maîtres des méthodes de contrôle indirect^[2], connaissent bien la vertu de ce principe.

Si le but du jeu est clair et atteignable, les joueurs vont tenter de l’atteindre de la façon la plus efficace possible.

Un principe que l’inventeur du bon vieil acronyme SMART ne désavouerait certainement pas.

Pour conclure sur les buts…

Outre ses propres critères, McGonigal indique une autre définition du “jeu” formulée par le philosophe Bernard Suits : “Jouer consiste à tenter volontairement de surmonter des obstacles inutiles”.

Dans l’exemple des Sprints de Scrum, nous avons vu comment le fait d’ajouter un but qui peut paraitre superflu ou inutile – “faire la prédiction la plus précise possible de notre productivité collective dans un laps de temps défini” – est ce qui rend l’expérience vraiment captivante. Surmonter cet obstacle devient un super défi à relever; et dès que nous l’avons accompli, nous nous sentons en confiance pour relever d’autres défis plus ambitieux lors du prochain Sprint.

Ce processus est lié de près à la dimension motivationnelle des “achievements”, que nous explorerons plus en détails dans la section sur les systèmes de feedback. Mais d’abord nous allons nous pencher sur les règles de Scrum. Rendez-vous ici pour la deuxième partie !

Vous pouvez me suivre sur Twitter pour lire les dernières informations à propos de ce blog.

—–

Notes:
1.^Jane McGonigal (2011),Reality is broken, The Penguin Press, p. 21 / Non traduit en français.
2.^Voir Jesse Schell (2008), The Art of Game Design, MK publishers, p. 283 et suivantes / Version française: L’Art du game design, traduction d’Antony Champane.