On a beau créer une expérience captivante, ou s’évertuer à produire un solide design de règles et d’objectifs : si une personne se sent forcée à participer à l’activité qu’on lui propose, elle s’y ennuiera foncièrement. Dans cette quatrième et dernière partie, nous nous penchons sur le dernier aspect qui fait qu’un jeu est fun : la participation volontaire. Comment cette notion s’applique-t-elle à Scrum ?
La participation volontaire est au cœur du fun
Imaginez que vous n’ayez jamais joué à un jeu de dessin (du type “Pictionary”) et que je voulais vous transmettre mon enthousiasme pour ce genre de jeu.
“Le mot était “observatoire” !! C’était pourtant évident !” – conversation typique de Pictionary
Je pourrais vous en expliquer les règles et les mécaniques, vous dire que la meilleure équipe gagne, et faire le récit exaltant de sessions de jeu avec ma famille et mes amis.
Mais je ne crois pas que vous seriez bien convaincu(e) par mes explications. Peut-être seriez-vous freiné(e) par vos peurs ou préjugés. Il se peut que vous ne compreniez pas l’essence de l’expérience. Peut-être vous diriez-vous : “Est-ce que ce jeu est vraiment pour moi ? Je ne sais pas dessiner, ce sera la honte… Et on devra se juger les uns et les autres, est-ce que ça ne risquerait pas de causer des conflits dans ma famille ?”
Laissez les gens essayer et se faire leur propre opinion
Une approche bien plus efficace serait de jouer une partie avec vous. Au bout de quelques minutes, vous seriez probablement hilare, vous auriez oublié vos doutes initiaux et réalisé que les dessins ratés sont en fait l’une des raisons qui font que ce jeu est si génial.
De la même façon, si vous n’êtes pas convaincu(e) que Scrum est une méthode convenable pour votre équipe, une longue explication ne vous rendra pas plus enthousiaste. Il est bien plus constructif de vous laisser essayer la méthode dans un environnement à faible risque, par exemple sur un petit projet.
Dans la plupart des cas, l’équipe constatera l’intérêt de Scrum car :
- Se fixer des buts intermédiaires et les atteindre est motivant ;
- S’auto-organiser et coopérer au sein d’un ensemble de règles valorise les capacités de l’équipe ;
- Recevoir du feedback régulièrement apporte une satisfaction et nous permet d’apprendre.
Il est fort à parier que l’équipe trouvera que Scrum est “fun” à utiliser ! Par la suite, elle choisira logiquement cette méthode plutôt qu’une méthode plus “traditionnelle”.
Cependant, si à la fin de la période d’essai les membres de l’équipe ne perçoivent pas les bénéfices de la méthode, il faut à tout prix éviter de l’imposer de force. Il se peut qu’ils aient une très bonne raison d’y résister.
Considérez que la résistance est justifiée
Trop souvent, les organisations tentent de déployer Scrum mais n’adoptent pas la philosophie Agile. Cela peut être catastrophique, car l’esprit des règles est alors dénaturé pour servir un système de management axé sur le contrôle.
Voici quelques exemples d’utilisations non-Agiles de Scrum :
Les points de vélocité sont utilisés pour un suivi de performance individuel, ou pour requérir des niveaux de productivités sans cesse plus élevés ; les rétrospectives sont détournées par des managers en quête de bouc-émissaire ; des “Sprints de planification” apparaissent, ne produisant rien d’autre que de longues listes de spécifications…
Pousser une équipe à utiliser Scrum sans adhérer à la culture Agile peut mener à un rejet massif – et justifié – de la méthode.
Imaginez qu’on dénature les règles du Pictionary de la même manière :
- Vous devez jouer au jeu chaque jour et devez atteindre quotidiennement un score minimum, faute de quoi vous êtes privé(e) de dîner.
- Les premiers tours de jeux sont remplacés par des tours de “planification de jeu” où vous devez évoquer tous les mots qui pourraient être dessinés, puis préparer et présenter un document explicitant votre stratégie pour les 22 prochaines sessions de jeu.
- À chaque fois que vous produisez un dessin que votre équipe ne peut pas deviner, on vous montre du doigt et on critique votre absence de talent.
- Si vous échouez trop souvent, on vous exclut du jeu, mais vous devez tout de même rester pour regarder, tandis que votre équipe vous reproche de les avoir retardés.
Jouer avec des amis serait probablement moins fun si on vous punissait pour cela.
Même si le design des règles est robuste, si l’un des joueurs rejoint la partie avec un agenda caché, les autres joueurs ne manqueront pas de le remarquer.
Le design de Scrum vise à accroître l’autonomie d’équipes pluri-disciplinaires. Son utilisation comme outil de contrôle des salariés est vouée à l’échec.
Pour que Scrum reste fun, toutes les parties doivent participer à l’activité dans le même état d’esprit de confiance et de bonne volonté.
Cela signifie que les équipes doivent avoir le droit de faire des erreurs et d’apprendre de leurs erreurs. Bien souvent, c’est ici que se trouve le point d’achoppement des transformations Agiles. Dans des organisations caractérisées par l’évitement du risque et possédant des processus bien établis, l’idée de célébrer les échecs est un véritable changement de paradigme.
“Nous valorisons les individus et leurs interactions plus que les processus et les outils” – Manifeste Agile
Jouez avec la méthode
La participation volontaire signifie qu’il faut écouter l’équipe et la laisser suffisamment libre d’expérimenter. Peut-être que Scrum ne marchera pas pour telle équipe, parce que la méthode est trop contraignante. Ou peut-être est-ce parce qu’elle ne gère pas un projet, mais plutôt un flux constant de tâches similaires. Dans tous les cas, vous ne le saurez jamais avant d’avoir testé la méthode et de vous l’être appropriée.
Si vous ne l’avez jamais utilisé, je vous encourage à essayer Scrum. Et si ça ne fonctionne pas comme vous le souhaitez, amusez-vous avec la méthode ! Continuez d’expérimenter.
Le but d’Agile est simplement de bâtir un cadre stable qui donne aux personnes suffisamment de marge de manœuvre pour résoudre les problèmes de manière créative. Après tout, n’est-ce pas la raison pour laquelle on veut embaucher des êtres humains, et non des machines ?
—
Cet article conclut notre série en quatre temps sur Scrum. J’espère que vous l’aurez trouvée intéressante ! Si c’est le cas, n’hésitez pas à partager cet article sur les réseaux sociaux ou à donner votre avis dans les commentaires.
