Les 8 postures du Scrum Master - 4. Le Scrum Master en tant qu'Enseignant
Auteur : Barry Overeem - 100% Scrum Master
Source : The 8 Stances of a Scrum Master - Scrum.org Whitepapers
Date : 09/2016
Conclusion
Ce chapitre contient quelques exemples de ce qu'un Scrum Master peut enseigner à une Équipe de développement, un Product Owner et une organisation. La plus importante leçon que j'ai apprise est qu'il est vain d'essayer de tout enseigner à l'équipe dès le départ. Donnez leur la possibilité de se tromper et d'apprendre de leurs erreurs. Rappelez-vous que les erreurs constituent les portes de la découverte (James Joyce).
Source : The 8 Stances of a Scrum Master - Scrum.org Whitepapers
Date : 09/2016
Traducteur : Fabrice Aimetti
Date : 16/10/2016
Traduction :
4. Le Scrum Master en tant qu'Enseignant
Ce chapitre parle du Scrum Master en tant qu'enseignant. J'y exposerai la définition d'un enseignant, le point de vue théorique de ce qu'un Scrum Master devrait enseigner avec quelques exemples pratiques.
Qu'est-ce qu'un Enseignant ?
La définition la plus juste que j'ai trouvée est : "Quelqu'un qui aide les autres à apprendre de nouvelles choses". Enseigner, c'est transmettre des connaissances ou des compétences et instruire à quelqu'un comment faire certaines choses.
Voici quelques bonnes citations :
- "L'art d'enseigner, c'est l'art d'aider à la découverte". - Mark van Doren
- "Je n'ai jamais enseigné à mes élèves ; j'ai seulement essayé de créer les conditions pour qu'ils apprennent." - Albert Einstein
- "Un bon enseignant sait inspirer l'espoir, déclencher l'imagination et insuffler un amour de l'apprentissage." - Brad Henry
Le Scrum Master en tant qu'Enseignant
Selon le Guide Scrum, le Scrum Master est responsable de s'assurer que Scrum est compris et mis en oeuvre. Les Scrum Masters le font en s'assurant que l'Équipe Scrum adhère à la théorie Scrum, à ses pratiques et ses règles. Ils guident l'équipe à revenir vers les principes et les pratiques Agile lorsqu'elle s'égare. Lorsqu'il enseigne, le premier point d'attention du Scrum Master porte sur l'Équipe de développement et le Product Owner. Mais le Scrum Master doit également garantir que Scrum est compris par toutes les personnes qui entreront en contact avec l'Équipe Scrum.
Que doit donc enseigner un Scrum Master ?
- Enseigner l'Agilité durant le démarrage de l'équipe. La première semaine, avec une nouvelle équipe, j'emmène toujours l'équipe au coeur de l'Agilité et de Scrum. Je leur apprend le pourquoi & le quoi de l'état d'esprit Agile, du framework Scrum, de XP et de Kanban. Même si certains membres de l'équipe peuvent avoir une certaine expérience de l'Agilité, je souhaite qu'ils soient tous sur la même longueur d'onde. Expliquer le Manifeste Agile et insister sur le fait que le développement d'un produit est basé sur des hypothèses : le client sait ce qu'il veut, les développeurs savent comment le fabriquer et rien ne changera par la suite. En réalité, le client découvre ce qu'il veut, les développeurs découvrent comment le fabriquer, et les choses vont changer tout du long.
- Enseigner les fondamentaux de Scrum. Utiliser Scrum peut se comparer à jouer aux échecs. Soit vous jouez en suivant les règles, soit vous ne le faites pas. Scrum et les échecs n'échouent pas et ne réussissent pas. On y joue ou on n'y joue pas. Ceux qui jouent aux deux jeux et qui continuent à pratiquer peuvent devenir très bon aux échecs. Dans le cas des échecs, ils peuvent devenir de Grands Maîtres. Dans le cas de Scrum, ils peuvent devenir de bonnes organisations en développement, chéries par leurs clients, aimées par leurs utilisateurs et craintes par leurs concurrents (lien). Certaine équipes commencent à utiliser Scrum en écartant certaines parties du framework. Par exemple, tenir une mêlée "quotidienne" deux fois par semaine, mélanger les différents rôles et laisser tomber les rétrospectives. Si l'équipe pense que c'est sage de le faire, c'est ok, mais le Scrum Master doit l'informer des conséquences et aussi insister sur le fait qu'elle ne fait pas du Scrum.
- Enseigner les différences entre Scrum et les bonnes pratiques. De nos jours, beaucoup de bonnes pratiques se sont entrelacées dans les fondamentaux de Scrum. Il est utile d'enseigner à l'équipe les différences. Des exemples de bonnes pratiques sont d'utiliser les points de story, tenir la mêlée quotidienne ou utiliser un burndown chart pour suivre visuellement les progrès. Toutes de bonnes pratiques, mais pas obligatoires en ce qui concerne les fondamentaux de Scrum.
- Enseigner à l'équipe comment se créer une identité partagée. L'équipe doit être consciente des conditions de travail en équipe. Que faut-il pour être une équipe ? Qu'est-ce que cela signifie d'être une équipe ? Je demande parfois aux membres de l'équipe de partager quelques expériences personnelles qu'ils ont eu dans les équipes dont ils ont fait partie. Quelle a été la pire équipe et pourquoi ? Quelle a été la meilleure équipe et pourquoi ? Un exercice puissant pour créer une identité partagée est de rédiger un manifeste de l'équipe.
- Enseigner à l'équipe l'importance de la vision produit. C'est aussi le moment où le Product Owner arrive. L'équipe a probablement été crée pour un objectif donné, par exemple construire un nouveau produit. Il est crucial que l'équipe sache et comprenne la vision que le Product Owner a pour son produit. L'équipe peut uniquement prendre les bonnes décisions si elle comprend le but du produit. Une vision claire agit fondamentalement comme un phare pour l'Équipe de développement, et se révèle particulièrement nécessaire dans les moments difficiles.
- Enseigner à l'équipe l'auto-organisation. Comme le dit le Manifeste Agile : "les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées." Une équipe auto-organisée est un groupe de personnes motivées qui travaillent ensemble vers un but commun, qui ont la capacité et l'autorité de prendre des décisions, et qui s'adaptent facilement à des besoins changeants. Un Scrum Master, en tant que promoteur de Scrum et de l'auto-organisation, devrait réfléchir à la façon d'aider une équipe à découvrir ses problèmes elles-mêmes et à proposer des outils, formations et idées sur la meilleure manière de le faire (Verheyen, Gunther. Scrum: A Pocket Guide).
- Enseigner les rôles de l'Équipe Scrum. Demandez à l'équipe de compter sur le fait que les gens autour d'eux joueront complètement leurs rôles. Si ce n'est pas le cas, cela devient un obstacle (Adkins, Lisa. Coaching Agile Teams). Enseignez à l'équipe la manière dont les trois différents rôles s'imbriquent ensemble. Le Product Owner souhaite réaliser la bonne chose, l'Équipe de développement souhaite la fabriquer de la bonne manière et le Scrum Master souhaite la fabriquer rapidement. Une super équipe sait comment trouver un équilibre entre ces intérêts différents.
- Enseigner à l'équipe la façon dont on traite les obstacles. Dans Scrum, un obstacle est tout ce qui empêche l'équipe d'être productive. C'est le boulot du Scrum master de s'assurer que les obstacles sont supprimés. Le Scrum Master supprime uniquement les obstacles qui dépasse les capacités d'auto-organisation de l'Équipe de développement. Sinon, il ne s'agit pas réellement d'un obstacle, mais juste d'un problème que l'équipe doit résoudre par elle-même.
- Enseigner à l'équipe comment visualiser les progrès. La transparence est l'un des piliers de Scrum ; elle est cruciale pour l'inspection, l'adaptation et l'auto-organisation. Du coup, le besoin de visualiser les progrès devient assez évident. Sans cela, les mécanismes d'auto-correction ne se mettent pas en place. C'est à l'Équipe de développement elle-même de choisir ce qu'elle va visualiser. Visualiser les Backlogs de Produit et de Sprint est une bonne pratique que j'encourage fermement d'utiliser. D'autres pratiques possibles pour visualiser les progrès ou améliorer la collaboration sont par exemple les burndown charts, le tableau des obstacles et des améliorations, montrer la disponibilité des membres de l'équipe ou créer un calendrier du sprint qui montre tous les événements et réunions.
- Enseigner au Product Owner comment gérer le backlog. Le Scrum Master doit enseigner au Product Owner comment créer un Backlog Produit, comment l'ordonner en se basant sur les priorités, la valeur, le risque et les dépendances et comment impliquer toute l'équipe dans cette gestion du backlog.
- Enseigner Scrum à l'organisation. Le framework Scrum peut se révéler très disruptif pour certaines organisations. Cela peut causer des changements que certaines personnes peuvent trouver difficiles à gérer. Expliquer l'objectif de Scrum et le besoin de certains changements est important pour créer une compréhension mutuelle et construire les fondations qui permettent aux changements d'être pérennes.
- Enseigner à l'équipe comment s'amuser ! Ne prenez pas tout au sérieux. S'amuser (NdT : se tramuser) permet de gérer des situations difficiles, de renforcer la collaboration et de construire l'esprit d'équipe. Par conséquent, assurez-vous que l'équipe ait l'occasion de s'amuser au jour le jour.
Conclusion
Ce chapitre contient quelques exemples de ce qu'un Scrum Master peut enseigner à une Équipe de développement, un Product Owner et une organisation. La plus importante leçon que j'ai apprise est qu'il est vain d'essayer de tout enseigner à l'équipe dès le départ. Donnez leur la possibilité de se tromper et d'apprendre de leurs erreurs. Rappelez-vous que les erreurs constituent les portes de la découverte (James Joyce).
