Le feedback est un aspect décisif des interactions humaines. Que ce soit dans l’éducation, les jeux, le management, dans le design ou dans les relations interpersonnelles, la manière dont nous communiquons à autrui s’il a répondu à nos attentes peut avoir une forte influence sur son futur comportement. Les boucles de feedback sont donc un aspect crucial dans la conception d’une expérience, et elles sont l’une des principales raisons du succès de Scrum en tant que méthode.
Après nous être intéressés au but (partie 1) et aux règles (partie 2), nous allons poursuivre l’exploration du fun dans Scrum avec le troisième trait caractéristique d’un jeu : le système de feedback.
Qu’est-ce qu’un bon système de feedback ?
Nous pourrions lister un grand nombre de choses qui garantissent la robustesse d’un tel système; pour des raisons de clarté, nous allons les regrouper en 3 grands principes.
Un système doit être conçu de façon à ce que le feedback reçu soit :
- Riche – chaque action déclenche une réaction directe et, si possible, une abondance de réactions ;
- Non-ambigu – nous sommes capables d’interpréter facilement si le feedback est positif ou négatif ;
- Instructif – il nous aide à voir les conséquences de nos actions et nous montre comment nous améliorer.
Un feedback riche
Rappelez-vous la dernière fois que vous étiez dans un ascenseur : vous avez appuyé sur un bouton et vous vous êtes probablement attendu(e) à ce qu’une lumière s’allume, ou qu’un numéro d’étage s’affiche. Avez-vous déjà pris un ascenseur où il ne se passait rien lorsque vous appuyiez sur le bouton ? Cela m’est arrivé récemment, et je peux vous dire que j’ai tout de suite trouvé cela très agaçant.
La mise en place de voyants lumineux a probablement évité le massacre de nombreux boutons d’ascenseur.
Vous trouverez des situations du même genre un peu partout, car le fait d’indiquer, d’une façon ou d’une autre, que l’action d’un utilisateur a été prise en compte est désormais une bonne pratique dans tous les champs du design. Et il y a une condition pour que cela fonctionne : la réactivité.
Le feedback doit être aussi rapproché que possible de l’action effectuée, sinon cela crée de la frustration.
Dans les jeux vidéo, les designers doivent s’assurer que le jeu réagit immédiatement aux actions du joueur, de crainte que l’expérience devienne vite agaçante… comme un bouton d’ascenseur cassé. Jesse Shell a une règle empirique pour cela : “Si votre interface ne répond pas à un input du joueur en moins d’un dixième de seconde, le joueur va penser qu’il y a un problème avec l’interface”[1].
Prenons un jeu comme Mario Kart – si vous ne connaissez pas, vous pouvez en voir un exemple ici. Comme tous les jeux Nintendo, il est très réactif, et le petit kart répond diligemment à toute action que vous réalisez.
Mario Kart est un jeu palpitant où de joyeux personnages Nintendo s’affrontent dans une folle course de kart.
Observez également la densité des sons, explosions, secousses, rebonds, les expressions rigolotes des personnages, les flammes, les pièces d’or, les étoiles, etc. Même si vous n’avez aucun talent pour la course, la quantité d’interactions présentes dans le jeu rendra l’expérience exaltante.
Outre le retour d’information immédiat, on trouve dans Mario Kart des rappels réguliers de la vue d’ensemble : nombre de tours restants, position des concurrents, objets en votre possession. Et à la fin de chaque course, un tableau des scores indique votre progression dans le classement général.
Quand il s’agit de feedback, la quantité compte.
Si l’on regarde Scrum, l’on observe qu’il inclut beaucoup plus de boucles de feedback que les méthodes de gestion de projet traditionnelles. Des boucles courtes, moyennes et longues s’entrelacent, ce qui augmente logiquement la fréquence du feedback.
Comme dans un système de jeu, Scrum prend le plus petit niveau d’action significative réalisée par l’équipe (= une tâche) et s’assure que chacune de ces actions déclenche un feedback systématique.
Le fait de suivre les tâches à travers des boucles de différentes longueurs nous permet de visualiser plus aisément les conséquences de nos actions :
- Le mouvement des tâches à travers le tableau, depuis “A faire” jusqu’à “Fini”, en passant par “En cours”, se produit plusieurs fois par jour.
- Ensuite vient le décompte quotidien de la vélocité d’équipe, avec la réunion journalière et la mise à jour du burndown.
- A la fin de chaque Sprint, la Démo et la Rétrospective ferment une boucle plus longue, celle qui donne un retour sur les buts intermédiaires.
- Enfin, la mise en perspective et la comparaison de tous les Sprints précédents permet à l’équipe de constamment réévaluer sa capacité à atteindre le but ultime.
Faites la comparaison entre ces différentes boucles et la situation dans de nombreuses organisations, où il n’y a qu’un seul moment possible pour mesurer formellement si la performance d’un employé est sur la bonne voie : la fameuse évaluation annuelle. Evidemment, un bon manager donnera régulièrement du feedback de manière informelle ; mais on voit qu’il n’y a qu’une seule boucle qui soit formellement inscrite dans le système, et elle ne se ferme qu’une seule fois par an !
Scrum ramène la densité un peu plus près de Mario Kart (plaisante) que de l’évaluation annuelle (fastidieuse).
Un feedback non-ambigu
Non seulement le feedback doit être donné fréquemment, il doit également être facile à interpréter.
Pour partir d’un exemple simple, prenons un jeu d’éveil comme celui où les petits enfants doivent trier et encastrer des formes de couleur dans les bons emplacements. Comme l’objectif principal est de développer les facultés motrices et cognitives du bambin, et vu que ses capacités de raisonnement sont limités, le jouet doit lui signifier d’une façon claire et directe si ce qu’il fait est bien. Le tri de formes fonctionne très bien à cet effet, car il est facile pour l’enfant de voir s’il a placé la forme au bon endroit. Le jouet est le feedback.
C’est également un très bon outil pour les parents et les éducateurs, qui peuvent voir en un coup œil quel est le niveau de maîtrise de l’enfant, et le soutenir avec des encouragements ou renforcer ses accomplissements avec des “bravo” et des applaudissements.
Les jeux de tri de formes donnent une information claire aux enfants : la forme rentre, ou elle ne rentre pas.
C’est la même chose pour le feedback en général : il doit être à la fois simple et clair. Nous le qualifions de “non-ambigu” quand on peut le placer intuitivement entre les deux pôles d’un axe (bon/mauvais, rapide/lent, etc.).
Un système de feedback bien conçu parvient à suivre la progression vers un but, tout en donnant une évaluation des actions effectuées.
C’est pour cette raison que le tableau est si important dans Scrum, ainsi que dans les autres méthodes agiles.
Exemple d’un tableau de Scrum simple, donnant une photographie immédiate de la progression des tâches (ici à l’aide de Trello).
Déplacer une carte dans la colonne “Fini” est un moment de satisfaction, une reconnaissance du travail accompli, qui est une forme de renforcement positif. En déplaçant les tâches à travers le tableau, l’équipe Scrum est également capable de visualiser si ses efforts portent leurs fruits : c’est un outil pratique de suivi de la progression.
Un feedback instructif
D’un autre côté, quand on devient conscient qu’on fait des erreurs ou qu’on agit d’une manière sub-optimale, on devient également capable d’apprendre.
Quand il est lié à un cadre de référence spécifique, le feedback nous aide à nous situer et nous donne des pistes d’amélioration.
Si vous déménagez dans une nouvelle ville par exemple, il vous faudra un peu de temps pour être capable de créer un cadre de référence dans votre cerveau, qui vous permettra de retrouver votre chemin instinctivement. Quand on veut apprendre à se situer dans différents endroits, on procède généralement par une série d’essais-erreurs. Vous allez quelque part, essayez d’imaginez dans votre tête où vous vous trouvez, et ensuite comparez votre supposition avec une information en temps réel – en regardant une carte, ou en demandant à un passant.
Lorsqu’on est perdu, les passants sont une source bien utile d’information en temps réel.
Ceci vaut également pour les cadres abstraits, où nous voulons nous situer en relation avec des critères pré-établis.
Dans le cas de Scrum, les graphiques de burndown sont un complément utile aux cartes de tâches. Ils permettent de visualiser tout accident dans la progression de l’équipe, en jugeant de la progression au regard d’une matrice temps/vélocité.
Ainsi, dans le graphique ci-dessous, l’œil exercé perçoit immédiatement qu’un problème est survenu le septième jour (Day 7).
Manifestement, quelque chose a déraillé au Jour 7.
Dans cet exemple, on peut voir que l’équipe a échoué à atteindre l’un des objectifs du jeu – rappelons que le but était de “faire la prédiction la plus précise possible de la productivité collective dans un laps de temps défini”. Toutefois cet échec n’est pas dramatique. Comme dans un jeu, échouer dans Scrum n’est pas déprimant, car c’est juste une nouvelle occasion d’apprendre.
A l’instar des vieux jeux de plateforme Mario Bros, Scrum est basé sur l’apprentissage par l’expérience ; la méthode fait en sorte qu’il y ait toujours une occasion de répondre à un feedback négatif. Si un obstacle a surgi, il sera mentionné lors de la prochaine réunion journalière. Et s’il est lié à un problème plus important, il sera abordé pendant la Rétrospective à la fin du Sprint.
Avec la capacité à détecter des irrégularités dès qu’elles surviennent (feedback riche), et à identifier rapidement si quelque chose ne va pas (feedback non-ambigu), Scrum enlève la pression sur l’équipe, pour que celle-ci puisse se concentrer sur le plus important : apprendre. Or apprendre sans risque est quelque chose que notre cerveau adore. Ou, comme Raph Koster le disait dans une formule célèbre[2]:
“Le mot ‘fun’ n’est qu’un synonyme du mot ‘apprendre’.”
Je voudrais conclure ici sur l’importance de célébrer les succès. Le feedback positif, surtout quand il repose sur des données qui sont clairement liées au but et aux règles, joue un rôle important en renforçant notre croyance en nos chances de succès. Chaque but intermédiaire que nous atteignons nous rend plus confiant en nos capacités en tant qu’individus et en tant qu’équipe, renforçant notre sentiment de maîtrise.
Dans la prochaine étape de notre exploration de Scrum, nous nous intéresserons à l’épineux problème de la participation volontaire. Rendez-vous ici pour la quatrième et dernière partie !
Suivez-moi sur Twitter et Linkedin.
(Article initialement publié en anglais traduit par l’auteure elle même ! Original ici: http://colinepannier.com/why-is-scrum-so-much-fun-3)
—–
Notes:
1. ^ Jesse Schell (2008), The Art of Game Design, MK publishers, p. 231
2. ^ “Fun is just another word for learning”, Raph Koster (2005), A Theory of Fun for Game Design, Paraglyph Press, p. 46
