Mar 21

Compliqué versus Complexe

De Fabien Bataille dans la catégorie Agile, Organisation

Lors de la lecture du livre “Reinventing Organizations” de Frédéric Laloux, je suis tombé sur une citation de la différence entre ces deux concepts qui me paraissaient à priori similaires.

“Dans les systèmes compliqués, nous pouvons chercher la meilleure solution. Dans les systèmes complexes, nous avons besoin de solutions réalistes et d’itérations fréquentes” (pour converger peu à peu).

Il ajoute une métaphore de Jean-François Zobrist qui illustre cela:

“Un avion […] est un système compliqué. Il est composé de millions de pièces qui doivent fonctionner ensemble sans accroc. Mais tout est sur plan; si l’on change une pièce, on est normalement en mesure d’anticiper toutes les conséquences qui en découleront. Une assiette de spaghettis, elle, est un système complexe. Même si elle se limite à quelques dizaines de “pièces”, il est virtuellement impossible de prédire ce qui se passera si l’on tire sur l’extrémité d’un spaghetti qui dépasse de l’assiettte”

A la réflexion je pense que l’on peut aussi appliquer cela à l’humain, que l’on peut considérer comme un système.

Il est lui même composé de milliards de cellules, bactéries, virus, etc…. De même nous (humains) sommes en interaction croisées avec plein d’autres humains dans notre vie personnelle et professionnelle, ce qui tend à rendre tous nos choix et décisions du niveau complexe plutôt que du compliqué.

Nous sommes donc incités à ne pas chercher la ou les solutions, mais au contraire à en trouver une pas trop mal, la tester, regarder ce que cela donne, et itérer.

Après tout, nous avons appris à marcher comme ça 🙂

Depuis la publication de cet article, j’ai découvert un autre article intéressant autour de ce sujet. Voir ici => https://blog.goood.com/2019/03/08/pourquoi-la-methode-des-5-pourquoi-nest-pas-efficace-pour-les-problemes-complexes/

3 Commentaires

Mar 07

Pourquoi Scrum est-il fun? Partie 4 – La participation volontaire

De Coline Pannier dans la catégorie Agile, Jeu, Management, Scrum

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.

Faire un commentaire

Avr 22

Design Thinking

De Fabien Bataille dans la catégorie Actualité, design, innovation

Design Thinking / Tim Brown CEO of IDEO

Désirant en comprendre un peu plus sur le lien entre le “design” et l’innovation, sur les conseils de Frédérique Pain (en charge du département Design et User Experience sur les applications aux Bell-Labs France), je me suis plongé dans la lecture du livre écrit par Tim Brown qui est le CEO d’IDEO société renommée pour être parmi les 10 sociétés les plus innovantes de la planète.

Dans ce livre Tim Brown présente ce qu’il appelle le “Design Thinking”, qui prend sa source dans les travaux de Brunel sur la Great Western Railway en angleterre et qui l’ont profondément marqué dans sa conception que le design avait pour mission de façonner le monde.

Pour cette ligne de chemin de fer, non seulement les ingénieurs ont mis tout leur savoir faire dans la conception des trains et des voies pour qu’ils soient le plus efficaces possible, mais ils se sont aussi préoccupés de l’expérience des voyageurs en faisant en sorte que les ponts et le surplomb des voies donnent l’impression de flotter au dessus de la campagne.

Il est impossible de résumer ici tout le contenu de ce livre (les lecteurs pressés peuvent lire uniquement le dernier chapitre du livre où Tim résume lui même ce qu’il vient de présenter), j’ai néanmoins relevé les citations suivantes qui me paraissent pleines d’intérêt et parfois de bon sens et qu’il y a donc intérêt à propager 😉

“3 étapes dans l’innovation: L’inspiration, l’idéation (apparition de l’idée), et enfin l’implémentation.”

“Contraintes du designer: faisabilité, viabilité et désirabilité !”

“Conseil pour l’étude utilisateur: Regarder aux deux extrémités de la courbe de gauss pour étudier les utilisateurs qui vivent, pensent et consomment différemment des autres.”

“Evolution de l’humeur pendant un projet:

Espoir lors de la phase de collecte d’information,
Doute lors du classement des données et de la recherche de modèles et motifs,
Confiance lorsque la création de l’idée devient plus tangible et que l’on créé le premier prototype”

“Une façon de faire en sorte que les personnes essaient quelque chose de nouveau, c’est de construire sur des comportement qui leur sont déjà familiers.”

“La prédictabilité entraîne l’ennui, et l’ennui entraîne la perte de personne talentueuses.”

“Une tolérance à la prise de risque a autant d’importance dans la culture d’entreprise qu’elle en a dans sa stratégie business.”

“Toujours être sûr que chaque employé comprend, apprécie, et a la possibilité de contribuer à la vision globale de l’objectif.”

“Une histoire a besoin d’être répétée plein de fois avant que les personnes commencent à comprendre comment elle s’applique à eux, et encore plein de fois avant qu’elle puisse changer leur comportement.”

“Un prototype est un succès, non pas quand il marche sans problème, mais s’il nous apprend quelque chose de plus.”

“Un bon “designer” est quelqu’un qui a la possibilité d’identifier des motifs dans un bazar de données pour ensuite pouvoir synthétiser de nouvelles idées à partir de fragments de données, de faire preuve d’empathie avec des personnes différentes de lui même, et tout ça peut s’apprendre !”

“Plus vite nous rendons nos idées tangibles, plus tôt nous seront capable de les évaluer et au pire de les laisser tomber.”

“Une innovation est une bonne idée bien réalisée, ces deux parties sont toutes aussi importantes !”

Faire un commentaire

Mar 07

Pourquoi Scrum est-il fun? Partie 3 – Le système de feedback

De Coline Pannier dans la catégorie Agile, Management, Scrum

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é de feedback un peu plus près de Mario Kart (plaisante) que de l’évaluation annuelle (fastidieuse).

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

Agile, feedback, fun, jeux, scrum
Faire un commentaire

Jan 29

Pourquoi Scrum est-il fun ?

De Coline Pannier dans la catégorie Agile, Jeu

(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.

“Quelle galère ! J’espère que la vue sera belle…”

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.

Imaginez-vous un match de foot qui durerait 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.

Agile, Coline Pannier, games, jeux, scrum
1 Commentaire

Jan 28

Pourquoi Scrum est-il fun ? Partie 2 : Les Règles

De Coline Pannier dans la catégorie Agile, Jeu, Organisation, Scrum

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/)

Faire un commentaire

Jan 04

Scrum depuis les tranchées a été mis à jour !!

De Fabien Bataille dans la catégorie Actualité, Agile

Le petit livre “Scrum depuis les tranchées” a été mon premier contact avec l’agilité il y a bien longtemps, c’est un livre qui rentre directement dans le vif du sujet en suivant une équipe qui vient de passer à Scrum.

La première version est sortie en 2007, et Henrik (son auteur) vient de le revisiter en faisant part de ses commentaires au vu de son expérience et des choses qu’ils fait maintenant différemment.

L’agilité est une matière vivante qui n’arrête pas d’évoluer !

Il vaut le détour, à lire ici => Scrum-et-XP-depuis-les-tranchees-v2

Faire un commentaire

Mar 04

Passage de Scrum à Kanban

De Fabien Bataille dans la catégorie Agile, Entrepreneur, Kanban

Je suis tombé sur Twitter sur un article décrivant le passage de Scrum à Kanban par une équipe qui a expérimenté Scrum pendant 3 ans, avant de se heurter à des limites qui les empêchaient d’évoluer.

L’histoire est très intéressante à plusieurs points de vue:

L’équipe n’a pas renié l’Agilité puisqu’elle est passée de Scrum à Kanban qui est elle aussi une autre méthode Agile.
Ce n’est pas ici une histoire de transformation Agile qui n’aurait pas fonctionné puisque l’équipe a expérimenté Scrum en suivant correctement tout le cadre de la méthode pendant 3 ans.
Enfin l’équipe a su identifier les points qui les bloquaient dans la méthode Scrum pour pouvoir aller vers plus d’agilité tout en restant conforme à la philosophie.

Quelques points surprenants tout de même:

3 à 4 heures de réunion à chaque rétrospective d’un sprint de 2 semaines, c’est un peu riche. Il aurait sans doute fallu “timeboxer” la réunion et se concentrer uniquement sur le ou les 2 problèmes principaux.
De même la durée des réunions d’estimation est assez étonnante, peut être estimaient ils trop en avant dans le backlog au lieu de se concentrer uniquement sur ce qu’il est plausible d’embarquer dans les 2 sprints suivants.

Voir sur Medium.com