Avr 22

Design Thinking

(Précédemment publié par moi même le jeudi 30 septembre 2010 sur le blog creative network.blogspot.fr)

mais comme le sujet revient furieusement à la mode, revoici une fiche de lecture du livre fondateur sur le “Design Thinking”

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 !”

Mar 07

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

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.

Le système de feedback

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.

Le système de feedback

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.

Le système de feedback

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.

Le système de feedback

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.

Feedback system

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

Feedback system

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. A bientôt 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

Jan 29

Pourquoi Scrum est-il fun ?

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

Climbing

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

Football game

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, je vous dis donc à très vite 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.

Jan 28

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

 

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.

 

Scrum guide

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.

Fantasy role-players

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.

Monopoly - French version

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

Jan 04

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

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

Mar 04

Passage de Scrum à 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:

  1. 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.
  2. 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.
  3. 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:

  1. 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.
  2. 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.

 

View story at Medium.com

Fév 26

Une entreprise libérée, c’est quoi en 1 minute ?

Fév 18

Les risques organisationnels du Lean Management sur la santé au travail

Les risques organisationnels du Lean Management sur la santé au travail

Un article très intéressant sur la comparaison entre Taylorisme et Lean et les impacts sur la santé des employés.

(Edit. du 19-02-2015, lien ci-dessous mis à jour)

Voir ici.

Fév 17

Une nouvelle variante de Scrum, le Scrum détrempé !

Le Scrum détrempé

(Article original ici traduit avec la sympathique autorisation de l’auteur: )

De nombreuses entreprises se qualifient elles-même d'”Agile”. Agile est la dernière méthodologie à la mode pour réaliser les projets de développement logiciel. L’Agilité existe sous différentes variantes: comme Scrum, eXtreme Programming (XP), Rational Unified Process (RUP), etc….

Scrum est celle qui est la plus suivie actuellement. Généralement les entreprises utilisent une version spécifique adaptée à leurs besoins limités par les contraintes environnementales (processus liés à des facteurs de leur environnement ou de l’organisation.)

En savoir plus »

Sep 26

Les 5 dysfonctionnements d’une équipe

5 dysfunctions of a teamThe Five Dysfunctions of a Team

Les 5 dysfonctionnements d’une équipe

Parmi les livres que m’a laissé un ancien collègue avant de partir (Yves revient ! C’est trop triste sans toi !) , j’ai été intéressé par celui-ci traitant de l’esprit d’équipe.

En effet depuis ma première expérience assez traumatisante du management et où j’avais eu plus l’impression d’improviser que de vraiment manager, je n’ai de cesse de trouver la meilleure façon de faire (si tant est qu’elle existe).

Ce livre américain d’un gouru du management (Patrick Lencioni), best seller du New York Times 2002, est écrit comme un roman, donc agréable à lire.

Bien qu’il s’agisse d’une fiction, on ressent en suivant les personnages et ce qui leur arrive un sentiment de situations déjà vues dans la vie professionnelle et qui nous incite à réfléchir.

Le livre présente un modèle en pyramide (voir ci dessous) de 5 comportements que chacun des membres d’une équipe doit acquérir pour que l’équipe fonctionne.

Ces 5 comportements que l’on peut assimiler à des niveaux de maturité d’équipe se construisent les uns sur les autres. Le niveau supérieur ne pouvant être élaboré que si le niveau inférieur est là et consolidé.

 

dysfonctionnements

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tout commence avec la confiance.

On ne peut pas construire une équipe sans confiance. Il faut que les membres de l’équipe se fassent confiance entre eux et donc acceptent de laisser transparaitre leur vulnérabilité.

Un des frein à cette transparence est la peur d’être vulnérable. La tentation est grande de ne pas communiquer aux autres des informations sur sa vie privée ou sur ses défauts personnels pour ne pas donner prise aux critiques.

Ne plus avoir peur des conflits

Une fois atteinte la confiance entre les membres de l’équipe, il faut aborder le niveau supérieur, à savoir ne plus avoir peur d’aborder des points conflictuels concernant la marche de l’entreprise. Une évidence de la non atteinte de ce niveau est justement l’absence et l’évitement des conflits donnant l’impression d’une fausse harmonie au sein de l’équipe, alors que des conflits larvés s’accumulent.

A l’inverse ce niveau est réussi si les membres de l’équipe sont capables d’exprimer et défendre leurs points de vues mais aussi d’écouter ceux des autres pour pouvoir argumenter.

A la fin de ce “conflit”, quand une décision est enfin prise, les parties prenantes doivent être convaincues par cette décision, ou au minimum être engagées à la mettre en œuvre. Ce qui nous amène au prochain niveau.

L’engagement

Ce troisième niveau construit sur le niveau d’acceptation des conflits productifs, est celui de l’engagement.

En effet si le niveau deux permet d’avoir des “discussions franches” pour s’engager sur une décision, il est aussi primordial qu’une fois la décision prise, elle soit mise en action.

Un échec à ce niveau peut prouver que le conflit de l’étape précédente n’a pas été complètement épuisé et les décisions acceptées.

L’échec à franchir cette étape s’illustre par l’ambigüité des actions des membres de l’équipe. Leur actions n’étant pas claires en regard des décisions prises. Il peut être judicieux dans ce cas de revenir à l’étape précédente pour définitivement purger de précédents arguments ou aborder les nouveaux arguments qui n’auraient pas été pris en compte.

Responsabilité

Le quatrième niveau accessible uniquement, tout comme les autres niveaux, en cas de réussite du niveau précédent est l’acceptation d’être redevable des actions acceptés.

Un échec à ce niveau se voit par la fuite de certains membres de l’équipe face à leurs responsabilités ou bien la complaisance dans des résultats médiocres par rapport à l’objectif fixé.

Chacun devant pouvoir compter sur les autres membres de l’équipe, il est important que chacun endosse ses responsabilités pour que l’équipe avance.

L’attention aux résultats

Le cinquième niveau, “l’attention aux résultats” suite logique du niveau précédent, peut être biaisé par des problèmes d’égo et de statuts personnels. En effet certains peuvent vouloir faire passer leurs objectifs personnels avant les objectifs d’équipe ou d’entreprise actés précédemment.

Conclusion

Ce livre présente une solution pratique pour avoir une équipe plus efficace. Le modèle présenté est suffisamment simple pour qu’il soit facilement mémorisable, et l’on se prend à essayer d’identifier à quel niveau se trouve la majorité des membre de son équipe.

Le style de l’écriture du livre son forme de roman et son organisation permettent d’avoir la présentation de la méthode dans une première partie, puis dans une deuxième les potentiels problèmes et quelques solutions pour les régler.

Ces solutions se limitant la plupart du temps à l’exil des personnes talentueuses mais échouant à franchir toutes les étapes indiquées ici. Ceci, du fait de leur égo ou de leurs objectifs personnels en contradiction avec ceux de l’équipe et de l’entreprise.

C’est peut être sur ce dernier point, comment faire évoluer les personnes ayant des difficultés au travail d’équipe, que le lecteur reste un peu sur sa faim.

Bien que le livre présente une ou deux techniques, par exemple pour établir la confiance, j’aurai aimé que l’on en présente un peu plus, et pour chacun des niveaux. On atteint sans doute les limites du format d’écriture sous forme de roman supportant mal le mode catalogue.

Il est aussi possible que l’auteur parte du principe que ces qualités ou défauts humains sont inchangeables ou alors tellement difficile à changer qu’il vaut mieux changer les personnes que d’essayer de les faire évoluer.

Pour aller plus loin voir aussi: Tribal Leadership, Holacratie

 

 

 

 

 

 

Articles plus anciens «