Dans cette seconde partie, nous poursuivons l’observation de Scrum à travers les lunettes du game design. Dans la première partie, nous avions vu en quoi le fait d’avoir un objectif à court terme créait une expérience captivante. Penchons-nous à présent sur le deuxième facteur qui définit ce qu’est un jeu, à savoir les règles.
Lorsqu’on parle de jeux au 21ème siècle, on a tendance à penser automatiquement aux jeux vidéo. Mais dans le grand royaume des jeux, on peut facilement trouver des exemples qui n’impliquent pas l’utilisation de technologies complexes ou avancées. Des jeux sociaux tels que Mafia ou les Loups-Garous de Thiercelieux ne nécessitent qu’un ensemble de règles qui définissent le nombre de joueurs, le but du jeu et le type d’action que les joueurs sont censés faire ou ne pas faire.
C’est la même chose pour Scrum : on peut y ajouter de jolis instruments tels que des logiciels dédiés, mais au final la seule chose dont on a vraiment besoin pour se lancer c’est de connaître les règles. Celles-ci tiennent dans un document de 16 pages, le “Guide Scrum”, qui n’est pas sans rappeler le manuel d’un jeu de plateau.
J’ai reçu une copie du Guide Scrum lors de ma formation Scrum Master… Avez-vous remarqué le sous-titre ?
Je ne rentrerai pas ici dans le détail des règles de Scrum. J’aimerais juste mentionner un exemple que je trouve assez édifiant.
Les rôles
Les rôles sont une méthode de contrôle indirect bien connue ; ils sont souvent utilisés dans les jeux pour orienter les comportements dans une direction souhaitée. Pensez par exemple aux jeux de rôle classiques, où l’on s’attend à certaines caractéristiques pour chaque personnage : l’archer est rapide et vulnérable, le guerrier a une grosse armure et peut encaisser beaucoup de dégâts, le sorcier est puissant et dépendant de ses potions de mana, etc.
Compétences de jeu de rôle au niveau max.
Évoluer dans un cadre établi revient à restreindre notre liberté, ce qui nous force à focaliser notre créativité dans le but de résoudre un ensemble précis de problèmes; c’est le fonctionnement de base du gameplay. Mais cela vaut aussi dans la vraie vie. En rentrant dans un rôle, nous limitons volontairement le type d’actions que nous pourrons effectuer. Cela nous pousse également à remplir les obligations qui sont attachés à ce rôle et à ce qu’il représente.
Le fait d’avoir un rôle nous confère :
- Un sentiment de pouvoir d’action (“agency”), car nous contrôlons notre domaine de travail (autonomie);
- Une mission spécifique à remplir pour le bien de l’équipe (sens du but).
Il existe 3 rôles en Scrum: Le Product Owner, le Scrum Master et l’Equipe de Développement.
L’intitulé des rôles dans Scrum ne donne pas seulement une idée claire de leur fonction, il agit également comme une prophétie auto-réalisatrice, affirmant la capacité des membres de l’équipe à relever le défi.
Pour les deux rôles qui doivent être joués par des individus, on note que les titres indiquent clairement l’étendue de leur pouvoir (‘owner’ / ‘master’) et ce sur quoi leurs efforts doivent porter (la vision produit / l’application de la méthode).
Le troisième rôle, “L’Equipe de développement”, est joué par plusieurs personnes dont les titres individuels sont volontairement non-définis. Il revient au groupe de s’auto-organiser et de décider comment il accomplira sa raison d’être : de livrer le produit, quel qu’il soit, que l’équipe Scrum a entrepris de créer.
Règles et espaces de liberté
Il y a d’autres règles en Scrum qui sont volontairement laissées à l’appréciation de chaque équipe. C’est le cas notamment de ce qu’on appelle la “définition de Fini” (ou “définition de Done” = quand une tâche est considérée comme étant finie).
Cet espace de liberté au sein du cadre établi fait des membres de l’équipe les véritables dépositaires des règles et des standards qu’il choisissent de suivre. La notion de “Fini” n’est valable que pour l’équipe Scrum qui s’est collectivement accordée sur sa définition, ce qui en fait un moment important pour aligner les visions au sein de l’équipe. Il est crucial que ces critères soient définis et acceptés par les membres de l’équipe eux-mêmes, et non par une quelconque autorité extérieure.
Quand une équipe devient experte dans l’utilisation de Scrum et d’Agile, elle commence à interpréter d’autres aspects de la méthode à sa façon. Si vous aimez les jeux de plateaux, vous savez que les bons jeux ont des règles claires mais que les joueurs aiment bien les contourner quand c’est nécessaire.
Quand on sait ce qui fait qu’un jeu est fun, on peut prendre quelques libertés avec les règles.
Comme quand je jouais au Monopoly avec ma famille étant enfant, nous n’hésitions pas à contourner les règles quand elles se mettaient en travers du plaisir de jeu partagé. Par exemple le propriétaire d’un hôtel Rue de la Paix ou Avenue des Champs Elysées (tristement célèbres car elles étaient les cases les plus chères du plateau) acceptait d’offrir le passage à un joueur proche de la faillite, afin que nous puissions tous continuer à profiter du jeu.
La dernière ligne droite du Monopoly de mon enfance, et ses redoutables rues hors de prix.
Les équipes qui débutent dans l’utilisation de Scrum disent souvent que, même si les règles sont assez faciles à comprendre, il est parfois difficile de les mettre en place. Perfectionner son utilisation de Scrum peut s’avérer un challenge intéressant en soi. Comme tous les bons jeux, il est facile à apprendre et difficile à maîtriser. Et s’efforcer d’appliquer strictement toutes les règles peut gâcher le plaisir.
De ce point de vue, le Manifeste pour le développement Agile peut être un bon guide pour préserver l’esprit des lois. Il faut garder en tête que la philosophie Agile derrière Scrum est encore plus importante que les règles elles-mêmes. Si un processus ou un outil entrave les individus et leurs interactions, il est nécessaire de s’en préoccuper.
C’est pourquoi les équipes qui sont plus matures dans leur utilisation de Scrum écrivent généralement leurs propres règles, choisissent d’enlever certains instruments ou d’en ajouter d’autres, ou parviennent de savants mélanges avec d’autres méthodes. Cependant, il faut du temps et de la pratique pour savoir quels sont les éléments qui peuvent être enlevés sans risques, et quels sont ceux qui sont essentiels à l’expérience.
Dans le prochain post nous nous intéresseront à la fonction centrale des boucles de feedback, à la fois dans les jeux et dans Scrum. Rendez-vous sur ce blog (la suite est ici), ou suivez-moi sur Twitter pour des nouvelles fraîches !
(Article initialement publié en anglais traduit par l’auteure elle même ! Original ici : http://colinepannier.com/2016/01/21/why-is-scrum-so-much-fun-2/)
