Scrum Master : guide 2020 en français par Scrum Life

Рет қаралды 10,791

Күн бұрын

Пікірлер: 15

@Be1can 3 жыл бұрын

Vidéo très bien. Néanmoins il manque juste, je pense, un dernier point : expliquer/enseigner l'intérêt de Scrum, des cérémonies, artefacts à la Scrum Team. En effet, il y a pas mal d'équipe qui font des Sprint review avec uniquement la démonstration ou alors faire un daily qui est plus un status meeting pour le manager que réellement un point de synchronisation de l'équipe pour l'équipe pendant la journée qui arrive.

@ScrumLife 3 жыл бұрын

Mais oui, bien sûr, tu as complètement raison !!! Ce point aurait mérité qu'on insiste plus. C'est en effet la partie "master", qui maîtrise Scrum, et qui l'enseigne. En plus, on avait fait une vidéo spécifiquement sur le sujet. L'as-tu vu ? Qu'en penses-tu ? Voici le lien : kzbin.info/www/bejne/Z4K0loisr9doadk À bientôt ! -- JP

@spip931 Жыл бұрын

Bonjour Scrum Life, J'ai plusieurs questions concernant le scrum master : - Comme vous le rappelez, dans le scrum guide il est écrit qu'"il n'y a pas (...) de hiérarchies" au sein de l'équipe scrum. Pourtant il est aussi écrit (et vous le rappelez également) que "Les Scrum Masters sont de véritables leaders qui servent la Scrum Team et l'ensemble de l'organisation." Ma question est donc : Comment, en tant que scrum master, être un "véritable leader qui sert la scrum team" sans pour autant "passer pour un chef" puisqu'il n'y a pas de hiérarchie ? Dit autrement, si quelqu'un d'extérieur à l'entreprise (un client par exemple) qui n'y connait rien à scrum, encore moins les termes et les rôles, demande à un des membres de l'équipe scrum "qui est votre chef/responsable ?", la réponse va naturellement être "c'est machin(e) (le/la scrum master)". Répondre et faire comprendre à quelqu'un qui ne connait pas scrum, qu'"il n'y a pas de chef, il n'y a pas de hiérarchie dans scrum", c'est assez compliqué, surtout si c'est un client énervé qui appelle et qui veut "parler à votre chef/N+1". J'ai du mal à faire la distinction entre "un chef" et "un leader". Pour moi, un chef est forcément un leader dans le sens où il nous indique dans quelle direction on doit aller et ce qu'on doit faire pour y parvenir. La différence que je vois entre "un chef" et "un leader", dites-moi si je me trompe, c'est qu'on doit rendre des comptes à un chef, pas (forcément) à un leader. - Est-ce qu'un scrum master peut (même si je pense que ça n'est pas bien) avoir 2 voire 3 casquettes ou doit-il n'en avoir qu'une (seule) ? Autrement dit, est-ce qu'un scrum master peut être scrum master ET developer, peut être scrum master ET product owner, peut être scrum master ET developer ET product owner ou doit être UNIQUEMENT scrum master ? Dans la vidéo, Jean-Pierre dit qu'à un moment, pour le scrum master "il va être question d'aider l'organisation dans sa globalité à comprendre la planification en mode empirique (...) En pratique, ça veut dire que l'équipe devrait planifier la résolution de problème et non pas l'implémentation de solutions. La différence est assez importante et nous amène très très loin en terme de conséquences, de comment on s'organise." Je ne comprends pas la différence entre "la résolution de problème" et "l'implémentation de solutions". Est-il possible d'expliquer SVP ? Enfin, je suis très circonspect (et c'est un euphémisme) par rapport au rôle d'"évangélisateur" du scrum master. Au delà du fait que, et je suis d'accord avec vous, scrum n'est pas la réponse aux problèmes de la boite, je vois mal une entreprise embaucher un scrum master si, à la base, elle n'a pas déjà mis en place scrum, ou qu'elle n'a pas l'intention de le faire. Dans les 2 cas, et dès lors, à part dire "il faudrait peut-être mettre en place scrum dans tel ou tel service" je ne vois pas ce qu'un scrum master peut faire de plus en terme de prosélytisme scrum. D'autant qu'une entreprise n'attend pas la venue d'un scrum master pour mettre en place scrum ou dans un service, ou dans l'ensemble de la boite. En tout cas merci pour vos réponses Bonne journée 😉 Nicolas

@ghenimamezine5627 3 жыл бұрын

Hello, je pose ma question dans cette vidéo. Est-ce qu'un scrum master peut-être sur deux équipes à périmètres complètement différents ? Merci

@ScrumLife 3 жыл бұрын

Bonjour Ghenima merci pour la question. Pour mieux te répondre, je vais devoir t'en poser une : Quel serait l'intérêt visé ?

@ScrumLife 3 жыл бұрын

Salut Ghenima, on le déconseille car c'est alors difficile d'avoir un véritable focus. Un Scrum Master sur deux équipes n'est finalement sur aucune. Il ne fait souvent qu'un travail superficiel, sans réellement s'impliquer. C'est la même chose avec un designer qu'on partage entre plusieurs équipes (état de fait bien trop courant) : il n'appartient à aucune équipe. Qu'en penses-tu, toi ? Que te dit ton expérience ? -- JP

@cockpitLAB 4 ай бұрын

Ou se place le CTO dans cette équipe scrum ?

@ScrumLife 4 ай бұрын

Le ou la CTO a généralement une place de manager. C’est à dire qui a comme mission de guider les équipes vers un objectif commun qui a du sens et de s’assurer qu’elles ont les moyens de faire leur travail correctement. - Constantin

@ScrumLife 2 ай бұрын

Salut @cockpitLAB ! Merci pour ta question 🌟 Dans une équipe Scrum, le rôle du CTO (Chief Technology Officer) peut varier en fonction de la taille et de la structure de l'entreprise. Souvent, le CTO ne fait pas partie de l'équipe Scrum directement, mais il joue un rôle crucial en soutien. Il collabore avec le Product Owner et les Scrum Masters pour s'assurer que la vision technologique est alignée avec les objectifs du produit. Le CTO peut également intervenir pour guider les développeurs et s’assurer que les décisions techniques et les choix d'architecture sont en phase avec la stratégie globale. Et toi, comment vois-tu le rôle du CTO dans ton organisation ? Hâte de te lire ! #ScrumLife #Agilité #CTO #TeamWork 🚀 - Robin 🚀

@jackisjack_bysun 3 жыл бұрын

Je comprends ici que le Scrum Master est décrit comme un chef, sans l'être, qui veut tout faire faire, sans faire lui-même, il a la maîtrise (master) mais ne souhaite pas maîtriser, et toutes les tâches qui pourraient rendre service aux développeurs dans leur travail, pour les aider à se concentrer sur leur coeur de métier technique, à savoir organiser des réunion, rédiger des compte-rendu, être le point de contact principal avec le reste du monde, ...sont ici indiquées "hors de son périmètre". Comble du luxe : son rôle implique de faire son auto-proportion : il se multiplie. En synthèse : une chose qui ne fait rien, regarde le travail des autres et le critique, puis se multiplie, n'y a t-il pas là les caractéristiques d'un "parasite" lol ? Je vois le rôle d'un Scrum Master autrement : tout ce qui est indiqué en "hors périmètre" au début de la vidéo : un "super chef de projet technique", il produit de la valeur ajouté sur des tâches que les développeurs maîtrisent rarement. Si vous m'indiquez que 8 développeurs, dans un contexte de production logiciel sous tension (besoin flou, nouvelle technologie peu maîtrisée, sous-staffing, client exigent) parviennent à s'en sortir sans un vrai chef de projet, et à la place un Scrum Master du type "c'est-pas-moi-qui-fait", je me fais moine ! (J'apprécie les autres vidéos de votre chaîne, mais là je diverge !)

@ScrumLife 3 жыл бұрын

Salut Stève, merci pour ton commentaire ! On a bien sûr le droit de ne pas être d'accord 👍 J'aimerais repartir de l'exemple que tu donnes : "un contexte de production logiciel sous tension (besoin flou, nouvelle technologie peu maîtrisée, sous-staffing, client exigent)" Je te dirais que dans cette situation le Scrum Master a un rôle énorme à jouer, sans se positionner en chef de projet. Son rôle serait justement de s'assurer, de faire en sorte que les besoins ne soient plus flous -- sans faire lui-même une passe sur ces besoins, car le but n'est pas de rajouter un intermédiaire. Un intermédiaire en plus = téléphone arabe. Le but sera au contraire de rapprocher les développeurs de ceux qui émettent les besoins, dans un cadre sain et constructif, par exemple en partageant des outils comme l'Example Mapping. (si tu ne connais pas : kzbin.info/www/bejne/nXqnYZWlermrgLM -- cet atelier est une véritable petite bombe sur ce qu'il arrive à provoquer) Concernant une technologie peu maîtrisée, la question à répondre serait bien : "comment faire en sorte que l'équipe maîtrise ces technologies ?" Cela peut passer par de la formation, par l'implication d'experts externes à l'équipe (ce qui peut prendre la forme d'un mentorat par exemple) ou tout simplement faire en sorte de relâcher la pression sur l'équipe pour qu'elle ait le temps de se l'approprier. J'aime bien dire : "nul n'est tenu à l'impossible." On ne peut pas exiger d'une équipe sous-staffée et en manque de compétence de délivrer comme des experts du domaine. Et le rôle du Scrum Master est de faire comprendre cela tout aussi bien à l'entreprise, au "management", qu'au client. Pour ensuite utiliser des outils comme la vélocité ou le burn-up chart pour mesurer la véritable vitesse de l'équipe et aligner tout le monde sur la réalité : on n'ira pas plus vite que ça dans le futur proche. Mettre la pression à l'équipe n'aidera personne, il faut être réaliste et raisonnable. Quant au client exigeant, plus on arrivera à créer une relation forte et saine -- la fameuse "collaboration" citée dans le manifeste agile -- plus on arrivera à en tirer des bénéfices plutôt que de le subir comme un problème ! On a parlé plus haut des besoins flous : si le client est exigeant et qu'on arrive à l'impliquer pleinement dans le projet, on devrait réussir à capitaliser sur son exigence pour que les besoins ne soient plus flous par exemple. Je conclurai en disant que d'une certaine manière je suis d'accord avec toi -- un bon Scrum Master expérimenté sait jouer ponctuellement d'une posture "super chef de projet technique" (je reprends tes mots) si c'est ce dont l'équipe a besoin à l'instant T. *Mais*, il y a bien un "mais", toujours dans une logique de : "je fais ce qu'il faut maintenant pour que ça avance mais ce n'est pas la meilleure manière d'avancer, alors quel est mon plan pour que cela ne soit plus nécessaire à l'avenir ?" Un dernier point, Constantin aime bien dire que "le Scrum Master mouille aussi sa chemise." Il fait partie de l'équipe et comme les développeurs il a son rôle à jouer dans les succès et dans les échecs de l'équipe. Il n'a effectivement pas le droit de juste se dire "l'équipe ne marche pas, tant pis pour eux, ce n'est pas mon problème." J'ai l'impression que le fond de notre débat touche plutôt à : comment faire en sorte que le contexte devienne sain, plutôt que de me positionner au milieu des problèmes pour les faire marcher en l'état. Qu'en penses-tu ? En tous cas merci pour l'échange, on pourrait en faire un article de blog 😊 À bientôt ! -- JP

@k4nful 2 жыл бұрын

Que du bullsh*t théorique, aucun exemple concret. Ça se résume à du bon sens .

@ScrumLife 2 жыл бұрын

Bonjour K4nful ! Alors oui c'est théorique, c'est le but de la vidéo. Dans cette série, nous faisons à chaque fois une vidéo "théorique" sur l'explication du Scrum Guide pour chaque partie, mais aussi à chaque fois une vidéo "conseils" qui parle justement de choses que nous avons pu vivre et expérimenter. Voici celle sur les Scrum Master : kzbin.info/www/bejne/rqGpi4SmmNd6gMk qu'est-ce que tu en penses ? Pour la partie "bullsh*t", tu peux préciser ta pensée ? Qu'est-ce que tu trouve bullsh*t ? -- Constantin